Below is an article I wrote for the Service Orientation issue of the Microsoft Architecture Journal. The article wasn't published as text but rather as a video presentation which I created and narrated.
XB
Abstract
This article presents six key principles and tactics to successfully transition an existing system into an SOA model. The keys are not a recipe that must be followed in order. Rather, they are a set of principals and tactics that greatly improve the chances of success of an overall SOA strategy. They are evolutionary in nature and an architect must be constantly conscious of them and continually attempting to apply them.
Our systems are constantly in flux because our businesses are constantly changing. This naturally leads to an evolutionary process. An architect's role in this process is to maintain the vision and provide the leadership to achieve it. Maintaining the vision means keeping it up to date with the needs of the business, evolving it in a controlled way. Moving toward the goal requires leading not only the rest of the development team, but (typically) senior management as well. The principals and tactics described in this article assist the architect in leading an organization toward an SOA model, even when that model must change with the business.
Understand the Business Domain and Model
An architect must understand their business's problem domain and the business model well enough to find the natural lines of separation. The lines of separation provide potential boundaries between services. The problem domain will include it's lines of business and it's particular approach to the solution. The pieces that are of most interest are those that can or are being solved with IT.
For example in a business making coats and leashes for dogs and cats, the problem domain includes:
- design of coat and leash products,
- manufacture of product,
- sale of product,
- shipping of product,
- account relationship management,
- material supply,
- ...
Some of these problems have can be partially, if not fully, solved with IT. It really depends on the business model and the solution chosen. The lines of separation will depend upon the business model as well. For example there could be a natural division between dog products and cat products. The suppliers may be the same for both products, but the customers may be different. And certainly the product lines will be different. On the other hand there may be a more natural line of separation between product categories: coats vs. leashes. How these entities are treated and related in the IT end of the business completely depends on how how the company views its business.
Maintain a Dictionary of Domain Terms
It is important that everyone uses the same language when talking about the problem and solution. This seems pretty straightforward however each business and business domain has it's own lingo. The IT end of the business needs to be able to use terms that are not ambiguous or context sensitive. The key to doing this is creating and maintaining a dictionary of the key business and technical terms.
The dictionary of terms will largely come from knowledge of the business domain. The more that is understood about the business domain the more refined the dictionary terms will become. And visa versa; the more that we try to refine the language through a dictionary, the better we will understand the problem domain.
It is also possible to introduce new terms through the creation of a dictionary. However caution must be taken here. New terms must be added slowly to allow uptake and proper understanding by people using them. Typically, the only reason to add new terms would be to remove ambiguity. This can sometimes best be done through a qualifier, rather than a new word. For example, the pet products manufacturer makes harnesses. Different varieties of harness have different webbing and buckles. A particular configuration of webbing and buckle might be called a Carr. Everyone on the manufacturing floor knows what a Carr is and which harnesses include a Carr. Overtime, the specifications of the Carr change until there are 10 different varieties but everyone still refers to them as a Carr. However, when Carr is written up on a pick list the stock guys now have trouble figuring out which one to get. And the supply people aren't sure how much material they need to get any more because there is too much variation between the Carrs. The Carr has become a design template and what is needed are qualifiers to precisely identify which Carr is meant. Is it the Big Fat Carr, or the Skinny Little Carr?
It is equally important to get people in the domain to use the terminology properly. This, generally, happens over time and it starts with the Architect. The principle of Evangelizing the Vision helps with this. It comes down to the Architect using the terms (correctly) whenever he gets the chance.
Maintain a View of the Ideal System
In order to go anywhere, you need a destination in mind. An architect is primarily responsible for leading their team to Nirvana. That is your destination, but what / where is it?
The destination is the architect's view of the best system to serve the business needs. This should be system that is morphed from the current by a reasonable number of steps, rather than being a complete redesign. You should be able to see the system on the horizon. You should also be able to create intermediate views of the system, the steps between where you are now and where you want to be. The intermediate views are based on likely projects that could advance the system toward the goal.
What is a view and what does it consist of? A view is a conceptual, high level design or system model. There can be different view aspects, such as hardware / networking, services / communication protocols, data / access.... The aspects required will depend upon the significant requirements forcing the desired changes. It should contain the architects notes on what each element is (new and old), why it's there, when it might be created or retired.... These aren't formal documents to be reviewed by committee, they are drawings for the architect to keep track of where the system is and where she sees it going.
These views build a roadmap from the current system to the best system. But the best system will be a moving target and thus the map must be constantly updated. New business initiatives, industry requirements and architectural ideas will force changes in the goal and the steps toward that goal. Thus it is important that the views be kept in a format that is maintainable.
A secondary reason for creating and maintaining these views are to communicate the architect's ideas. These views are part of what the architect evangelizes. Thus they must be in the language of the business's dictionary.
Seek Opportunities to Advance the System
For any work to be done some kind of return must be expected. Every organization is different in how it approaches change and updates to its architecture. Most will not drop millions of dollars into a project that simply promises the Nirvana of the most extensible system, and they shouldn't. The return on such an investment, in the absence of immediately enabling new business, is likely to be low.
One very good reason for not attempting a big bang architectural change is the learning process that occurs along the way. No architect, no matter how good they are, can design a perfect system. They will learn new technologies, new information about existing technologies, new patterns, better ways to implement their patterns and so on. Breaking up the change into smaller manageable and methodical steps will greatly improve the chances of success. It also follows two basic tenants of Agile development: always seek to add the most value with the least amount of effort, and delay commitment to the last responsible moment. Make the changes that you need, when you need them, and nothing more.
The key is to find strategic opportunities to move toward the ideal system. Opportunities will come along that can be used to push the system forward. These opportunities will have the return on investment built into them, which makes them ideal for architecture changes that have an otherwise low ROI. They will come in different forms:
- new line of business
- new client(s) or partner(s) with slightly different needs
- integration with 3rd party software
- updates to 3rd party software
- ...
Many of these changes can be opportunities to advance the system towards an SOA model. The trick is to find the right mix of project and architectural change. Any architectural change is going to increase the overall cost of the project. It may also have collateral costs such as changes to work flows, documentation, operations, reports.... These costs need to weighed carefully against the overall project and the potential return in the end. Essentially we're looking for someone else to pay for the changes we want. And it boils down to two approaches:
Hide the architectural changes as necessary to support the project,
- Incorporate the architectural changes with the highest potential return.
Use the first approach sparingly. When it's used too often, it starts too look like the architect wants to gold plate everything. Every project takes too long and costs too much. This approach can be used to kick-start a set of changes, but the road map to higher return must be clear.
The second approach is the method for success. The general theme should be to find projects where the return to the company can be enhanced by making architectural changes (typically adding SOA aspects). The enhanced return will often be the potential to attract future revenue or reduce future costs. The ideal is to find a client who will pay for the changes you need to support them; along the way they pay to better your architecture. But more often it will be an internal business investment to add features, functionality or other improvements.
Each of these opportunities shapes the goal system and the road map toward it. As new projects come along with the potential to advance the architecture, the road map will need to change. The view of the ideal system and the opportunities that might lead there, work co-operatively. Opportunities will come up that enlighten new possibilities in the architecture. Even if the opportunities don't go forward, the architect may adjust the vision of the ideal system based on what she learned from the investigation.
Evangelize the Vision
The vision will not go anywhere, if the architect keeps it to himself. The company needs to see, understand and believe in his vision of the ideal system. The evangelization needs to happen at all levels. The architect needs to get developers, product owners and operations people speaking the same language. That means she needs to use the language from the dictionary she developed. She also needs to continually point people to the dictionary, particularly new employees. Developers need to see where the architect is leading them and why. They can and should ask questions about why he wants a particular set of services rather than some other set (keep an open mind to these ideas, one sure way to kill the advancement is to squash dissenting ideas). Directors and business leaders need to understand the benefits and rewards for moving in this direction rather than some other. They may have heard of SOA and web services but may also be cautious of the cost and complexity.
The architect must find and create opportunities to put forward her vision and the road map to that vision. Those opportunities can be in design meetings, architecture forums and even hallway conversations. The basic premise is to continually use and re-enforce the terminology and vision. When the evangelism is successful, other people in the company will begin using the same terms and promoting the same vision.
Continuously Improve Everything
It should almost go without saying, but everything an architect does should be continually reviewed and improved. This is no different than the Agile mantra of closing a file in better condition than it was when you opened it.
- Continually seek a better understanding of the business and domain
- Continually add and refine terms in the domain dictionary
- Continually update and refine road map to the ideal system
- Continually work on the evangelization pitch.
