Mining for Services with Solution Domain Architecture
In Microsoft IT, we are reapproaching the problem of SOA governance from two angles: bottom up and top down.
Bottom-up services are services that the IT teams build as part of their normal work. They are project focused, and tend to be fairly well aligned to line-of-business applications. If there is any reuse of these services, it is a happy accident. We make them visible across different IT teams, but they are primarily used by the teams that create them.
The exceptions are some minor generic bottom-up services that are developed by an 'edge project' using enterprise data. For example: we have an enterprise data store that contains information about employees and the corporate heirarchy. Using this data, it is fairly simply to construct an organizational chart. This data is available by subscription to a central MDM data service that we've had in place for years. That service is primarily ETL based, and does not offer up web services.
That said, if an app were to develop an internal web service that looks at this enterprise data and provides simple retrieval and analysis (to answer questions like 'where does Nick work?' and 'who is Nick's manager?') then the service could easily be reused across a wide array of applications. Why? Because the service is against enterprise data that every application needs to align with. While the service was developed "at the edge," it uses only "core" data, and therefore is useful for a wide array of applications. These services can be readily reused.
So bottom-up services are not the primary win for SOA agility. To compose an application out of enterprise parts, we need to bind together on enteprise data. For that reason, we need services that communicate using enterprise (and not local) data, using enterprise identifiers, in a manner that is consistent with enterprise needs. Those services are rare.
In fact, those services are nearly always the 'top down' services that we know, in advance, that we are going to need.
How do we know what services we need to create? Through Solution Domain Architecture.
Solution Domain Architecture in a Service Oriented Analysis method (part of SOPADOG) that we are pioneering in Microsoft IT to solve multiple problems:
- How do we guide various projects to create services that are actually needed by other business applications?
- How do we develop services that will allow us to compose agile applications?
- How do we minimize dependencies between systems while still creating an integrated infrastructure?
Solution Domain Architecture is an analysis method that starts by grouping the various functions of the enterprise around the data elements that are generically understood to be enterprise data (like invoice, product, asset, identity, etc). These groups are called Solution Domains (hence the name) and represent an abstract concept. The solution domain is the abstract collection of system features that are cohesively bound to shared data items. These sets form the "tools" part of a business capability.
(A business capability is a combination of people, process, technology and data. The Solution Domain is a mapping against the software part of the technology.)
There is a many-to-many relationship between business capability and solution domain. It is perfectly normal for a single business capability to require the features of multiple tools (like learning management needing tools in the domains of employee management, portal collaboration, and knowledge management).
There is also a many-to-many relationship between solution domains and the technical capabilities of our platform tools (like messaging, authorization, database management, and auditing). It is, for example, normal to find many tools that need database management. However they need them in different ways for different databases.
This creates a three-level view that places business capabilities on top, solution domains in the middle, and technical domains across the bottom. The diagram below illustrates a small subset of the areas, and their relationships.
(Click the diagram for a larger view)
It is important to note that this is NOT a stack diagram. Each solution domain contains a set of logical systems services. These services represent enterprise solution capabilities. When you make this mapping, each solution domain contains one or more systems, one or more services, and one or more databases. A solution domain may have many user interfaces. It may involve systems in many geographies. It may deliver capabilities to users using many different devices.
This perspective is not commonly seen, but it is essential to understanding how to create services.
Look for a moment at the wires. The wires between layers are dependency (for example, Partner Relations depends upon Relationship Management solutions, which depends upon Database Management technologies). In the model above, I used a light grey color to distinguish them. These links are useful to understand the demand that the business places on the layer below it. This is a planning concept. We want to know what solution domains are used by what business processes because we invest in business processes. This allows us to easily scope out the areas where an update to a business process will affect the tools. IT planning is all about the affect on the tools.
One nice thing about mapping this way: if the business strategy says "focus on a particular business process" then you should see your IT investment occur in the solution domains that are mapped to those processes. If you see your IT spending going to other domains, ones that are not mapped to the strategic processes, then you do not have good IT-Business alignment.
That's right. I can illustrate the 'level' of IT-Business alignment with this diagram, by adding 'heat map' colors.
Let that sink in.
Now, look at the lines between the solution domains in the same layer. These are data dependencies. I used a thicker line in the diagram above. For example, Obligation Management depends on Product Lifecycle Management. That is because we are obligated to deliver what we sell, and we only sell what we make, so to know what we sell, we depend on the list of products... which is managed in the Product Lifecycle Management solution domain.
These lines between solution domains represent the flow of information between domains. They represent the movement of business documents in response to business events.
In short, the lines between solution domains are the enterprise service dependencies. At one or both ends: a service endpoint.
It really is that simple. By understanding these dependencies, we can chart out the services that are needed to move the data. Those services are placed into the catalog before they are ever written, and the EA team learns about them and plans for them. Then, when a project is proposed, by the business, in Partner Relations, we can see that there will be an impact on Relationship management.
We then look at the planned services in Relationship Management. Let's say that we want there to be 10 services, but currently there are only four. So the project that the business proposed gets to add one more... because it is the right thing to do... and because by creating that service, perhaps we can now link to the collaboration domain. In other words, we can show customers their customer service request status on the web site (web portals are part of the collaboration domain).
At the core of this is the fact that these services are driven by the business, but planned by IT, and implemented on demand, when projects arise. That is Solution Domain Architecture.
[addenda: I want to add one bit that was pointed out by a friend: Solution domains are an attempt to help understand the demand for services from an enterprise perspective. There is nothing in Solution Domain Architecture that prevents or opposes the development of services for Line-of-Business specific needs. Those services are not fully captured by this method, but they are not opposed by this method either. In other words, top down and bottom up are quite happy together.]