Filling the SOA gaps

Hi guys,
Let's talk architecture again, reference architecture, more
specifically SOA, and how can we map the available products and resources available from Microsoft given a SOA project?
Before I start, let me make a statement here: I will talk this from the Microsoft's point of view, since this is a blog about Microsoft technologies.
In any case, it doesn't matter what's your preferred provider as long as you are able to correctly do the mapping of functionalities to better fit your business' plans, budget and SLA. And just to revisit: SOA is an architecture where the functionalities of existing business applications are exposed and published as services.
And what would be a service? Services are software components that expose application functionalities in a given SOA architecture and they are:
- self-manageable;
- message-based oriented;
- can handle and support many protocols;
- can be published on a myriad of hosts;
- implement operational contracts, interfaces and message types;
Of course you can design some service that doesn't follow these rules, but let me tell you: Rules are made with a purpose and in our case the purpose is to design a solution where clients and services are highly decoupled, thus paving the way for the reuse of functionalities. One of the goals is to maximize the resource utilization in our project.
I won't talk here about governance, granularity, message routing, service level control etc. I won't go there for it is a much larger topic, so this post is about the technical view. Now, let's make our first diagram given what we've seen so far:
As we can see, we have here the common services of a SOA architecture such as the presentation services, collaboration, systems integration, orchestration services etc.
Looking at this diagram we can identify the aspects that we really want to map in our solution to be successful. Note that in some scenarios sometimes the security is critical, sometimes the orchestration is paramount, sometimes the platform integration is more important.
Now, visualize this filling the gaps with the products that Microsoft has to offer.
An interesting conclusion we can take at first sight is that some products can cross domain frontiers and can handle various capacities at once, such as the Windows Workflow Foundation, which can be used for interoperability services and orchestration at the same time with BizTalk Server.
What's the best option to choose? Well, to be able to see this big picture and to choose the best piece in the puzzle is your job as architect. Unfortunately many architects fall in the problem to overkill the solution.
Also important is to choose not to overkill the solution. Sometimes a simple custom application can fill the gap enough to not require a bigger solution like Windows Workflow Foundation, for example. Otherwise the whole project just becomes harder to handle and to maintain...thus increasing the ROI overtime...and the developers patience.
The message to keep in mind: any good architecture is composed by many capacities. To identify these capacities and which one of them are important for our solution is as critical as choosing the technology provider.
See you later.