In my last article I introduced the power and use of topics within an enterprise messaging platform and provided some information about how Solace’s appliance utilizes topic names to deliver information to interested parties. In the second part of the series I want to provide suggestions about how organizations can leverage these features in a consistent way to maximize the value from their enterprise messaging capabilities. Additionally we’ll focus on considerations and suggestions when designing a governance model to make sure the best practices are leveraged whenever possible. These elements help drive adoption, reduce total cost of ownership and accelerate the learning curve as new developers interact with this technology.
The importance of this question is directly proportional to the size of the organization and project it’s being asked about. If you’re the sole person on a project performing development, SysAdmin, and Help Desk Guru tasks, then the answer should be obvious. Things are more complicated when you belong to a larger organization where different people or teams are responsible for supporting, monitoring, deploying, and designing the application, and a lot more people have a vested interest in the composition of your topic hierarchy.
Having a ‘big picture’ view of current and future application direction will help you make choices that lead to the right number of levels of your topic namespace to satisfy everyone from the developer to the NOC who has to watch for misbehaving applications. Making sure you have a grasp of what everyone expects from your application is a great way to make sure that the topic namespace has been designed in a way that meets everyone’s needs and makes their lives as easy as possible.
The sooner the better! In reality, there are two kinds of scenarios: new applications, and existing applications. If the application you’re responsible for is already using publish/subscribe middleware it’s already got a set of defined topics. Unless there is large benefit to be gained, such as faster time to market for new products using this infrastructure, decreased troubleshooting time (and it fails a lot), or the ability to provide more timely information to the powers that be, then re-engineering an existing topic namespace is rarely a project that gets the green light.
But if you’re developing a new application, or porting an application to a pub/sub architecture, you have a little more freedom. Even if the program you’re developing has to consume data from another topic namespace, you can always segment your own information by starting your own ‘high level identifier’ such as /MyNewProject/my/topic/levels
This list could probably fill a textbook, and the book would be different based on the application, the industry, the culture of your organization, and many other subjects. Some basic ones that almost always come up:
There’s a lot more to consider, including, who else uses messaging in your organization? Do they have a Topic Namespace approach you need to be aware of? Is there a process in place to exchange information to make sure you’re not overlapping your topics? (perhaps to disastrous results!) But these, and other questions will have to wait for another post.
Let me know about the additional questions you have about topic namespaces and governance and we’ll address them in the comments or if they’re more complicated and intricate we can write additional blog articles.