IFaP : Middle Out Architecture
There is some discussion these days about "middle out" architecture. The key idea in "middle out" is that it is neither top down nor bottom up. So what does that mean?
Top down architecture means to take the entire enterprise and create a model with large, vague, blocks of functionality. The architect then drills down on each block, adding details and fleshing out the design, until a sufficiently detailed design is created. It's basically Functional Decomposition 101.
Bottom up architecture means to allow different teams to create whatever services they want, set up an infrastructure for sharing them, and then stepping back, hoping magic will happen. Sometimes it does. Usually, it's just chaos.
You cannot craft a work of art by pouring a bucket of sand on the street, and you cannot craft an efficient enterprise by endorsing services and then standing back to 'watch things happen.'
Middle out architecture starts at the center. The goal of middle out architecture is to create a stable 'center' as an abstract combination of Identifier standard, Format standard and Protocol standard (an IFaP). This abstract combination is something that allows variation both in the business uncertainties (where a business would consume a service in a composable manner) and in technology uncertainties or variations (where the technologies to be consumed could be widely different). This is often illustrated as an Hourglass shape, with the narrow waist being the IFaP.
Most enterprises will need more than one IFaP. I can easily imagine one IFaP for Master Data Integration needs and another for Functional Services, and a third for Business Intelligence and perhaps a fourth for orchestrations and long running transactions.
Why the combination if Identifier, Format, and Protocol? What's magic about this combination?
I'll try to answer in a different way: what is magic about the Internet? What has allowed this technology to blossom and grow in a completely unregulated manner, with no single person, group, or organization driving it's growth? A couple of IFaPs. TCP/IP has all three. HTTP has all three. SMTP has all three. As does RSS. What do we get? We get rapid growth. It is not difficult to write a web server, an SMTP server, an RSS reader. Why? Because the standards are simple, understandable, and technology independent. The road to failure is well traveled by folks who have attempted to create a standard that didn't have all three elements, or didn't provide for versioning in each of the elements (versioned identifiers, versioned formats, and versioned protocols).
So, to make your SOA take off, start with an IFaP. You can and will certainly need more than that. You will need some elements of both top-down and bottom-up in order to drive adoption, make teams aware of their obligations to the enterprise, and make the services managable. You will need governance and a reliable infrastructure. That is critical. But so is an IFaP.
What does that mean? It means that you do more than just say "We will use SOAP" or "We will use REST". It means that you provide specific guidance about how all 'enterprise services' shall behave, and then you make it as easy as humanly possible to create services that behave that way. You make developers aware of the services, and allow them to call the services at will, without the need for heavy procedures and hand-waving and sign-offs.
You build in mechanisms to make sure that the 'enterprise services' are managable without the developers needing to know every detail about how those mechanisms do their work. It's a cross-cutting concern, and you can and should give them lots of details, but they shouldn't be forced to learn them all to use the system, any more than I have to know the intracies of Name Servers to write a simple web browser.
More importantly, if someone creates a service that you didn't include on your plan, embrace it. As long as it is compliant with the IFaP, then it should enter the enterprise as a first-class citizen. You still want to encourage specific services to be created and delivered, and you still want to insure that a funding model is in place, but you must not stifle creativity.
Over the course of the next few months, I hope to be working on an IFaP approach within Microsoft IT to making services accountable, discoverable, managable, very easy to develop, and very simple to use. I will report back to this blog about progress as it occurs, and any of the pitfalls that we run in to along the way.