This morning I went to an ArcReady seminar at the MS campus in Independence. Chris Madris, from MS Consulting Service, spoke on SOA Lifecycle Management.
Chris talked about best practices for creating and operating an SOA environment. Then he demo'd the MS Service Engine that MS Consulting Services has created to "Virtualize" services.
Chris presented the idea that there are three layers of services: Process Layer, Service Layer, and Integration Layer.
The Infrastructure Layer sits on the bottom and exposes systems to the enterprise. These might be wrappers around legacy systems or they might be stand alone services.
The Process Layer is at the top of the stack. It's home to the user interfaces and the business processes. Business processes could run in BizTalk, WF, or just hard coded sequences in applications
The Services Layer sits between the Infrastructure and Process Layers. It provides some abstractions and insulation to make it easier for the Process Layer to consume the Integration layer.
Business - IT Alignment
Chris had a nice recommendation on Business-IT alignment. He said that sometimes the business side can start to get pretty IT savvy. They'll start to understand how apps are built and how things run. Then when they need new or changed functionality, they'll suggest the implementation too. Often this implementation is a simple "tack it on" type addition.
Chris recommends that IT work with the business to separate the discussion into a couple stages:
1) The business determines the "capability" or functionality that they want. This is the "what".
2) Then IT proposes the implementation options. This is the "how".
3) Then business and IT discuss or negotiate the best option.
The Hidden Cost of Re-use
Chris explained that there is an interesting pattern to re-use of services in an organization. Let's say that group A builds an app and then exposes it via services. Then group B builds an app and re-uses group A's services in their app. This is great! It saved time and group B got up and running quickly.
Then group A needs to make changes to their service. They soon realize that they are now responsible for the well being of more than just their own app. They need to keep the other apps running smoothly. Now group A feels the "cost" of sharing. They were a good citizen by sharing their service, but in return, they got added complexity and responsibility. Now they start to think twice before sharing their services.
Next thing you know, the organization is back to silo'd systems and duplicate services because the groups don't have sufficient support from the organization to manage shared services.
Backing from the organization. The organization needs to see this from the big picture and provide sufficient support to those who run shared systems.
Infrastructure and tools to manage services.
Visibility to see who is using any given service so that the provider can make informed decisions about changes to the service.
MSE (Microsoft Service Engine)
MS Consulting Services wrote the MSE to help their customers. MSE is an infrastructure item that helps the organization with versioning, service virtualization, binding translation, message transformations, and the ability to inject policy into the stack.
See my previous post for more info. Or check it out on Codeplex.
Chris positioned MSE as a great option for the middle Service Layer. It can easily provide the abstraction and virtualization without the need to write additional services.
We can also use MSE to inject any kind of logic that we want into the call stack. This is done via a policy, written in XAML. He gave the examples of logging the operation to BizTalk's BAM engine for analysis, doing authorization checks, managing compliance auditing, etc. It can really do anything we need.
MSE is not an official MS product (yet), but it will have a migration plan to the upcoming Oslo project.