SOA: Making The Paradigm Shift Part 9 of N
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is useful, if posts too long, too abstract, your thoughts.
What SOA Design Approach Should I Take?
Now, that we have gone broad and general across IT, we need to look at at a Design Approach for Identifying, Designing and Building Services. Should we go Top-Down or Bottom Up? The answer is neither or actually a combination of both together with Agile techniques.
Nick Malik had a couple of landmark posts that influenced a lot of thinking, especially mine in the whole approach of SOA. The first was “Bottom-Up SOA is harmful and should be discouraged,” where he laid out the three kinds of SOA:
“There are three schools of thought around "how to build an Enterprise Service Oriented Architecture." They are:
- Top down - central group decides everything and the dev teams adopt them.
- Bottom up - central group provides a directory and dev teams make whatever services they want. Dev teams go to the directory to find services they can use.
- Middle out - central group provides key elements of the interface, including numbering schemes, message exchange patterns, standard communication mechanisms, and monitoring infrastructure, and encourages the dev teams to use it to build services that can be shared.”
He followed up with What you need to make Middle out SOA work. I highly encourage you to read both of them. They certainly are worth your time. I think this is a critical point to understand as it tends to shape whether your SOA efforts will succeed or fail.
I have rarely seen Top Down succeed. By the time your company has formed a central committee and “boiled the ocean” the money is usually gone and there are little results, and SOA is already labeled as a failure. On the other hand, and we certainly did this in my two years at Algo, most people are doing Bottom-up JBOWS. Development just stands up a service as needed. There are no directories, governance, registries, no SOA benefits. The immediate business benefit is there temporarily but the service is not agnostic enough or large enough for reuse.
Middle-Out SOA
While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service oriented efforts have been successful. SOA projects have limited success when they are driven from the bottom up by developers; building SOA for the sake of SOA without reference to the business context is a project without organizing principles and guidance; the result is a chaotic implementation that has no business relevance. On the other hand, taking a top-down mega-approach to SOA requires such enormous time investments that by the time the project is complete, the solution no longer maps to business needs.
The “middle-out” approach is a successful hybrid of the two other approaches. Business drivers and strategic vision are first employed to set clear direction and priorities. Based on these, the organization takes multiple iterative steps to build out slices of end-to-end capabilities, with each iteration delivering a new, dynamic application back to the business that is used to create business return. Microsoft has long advocated this “real-world” approach to leveraging service-oriented architectures: The approach is focused on rapid time-to-value, and it delivers business results through iterative, incremental steps that facilitate close alignment of IT resources with changing business conditions.
Based upon the clearly defined and prioritized vision, each implementation project is an iterative one of creating (“exposing”) new services, aggregating (“composing”) these services into larger processes, and making the outputs available for use (“consuming”) by the business user.
Expose – This phase focuses on which services to create from the underlying apps and data as well as how they are constructed.
Compose – Once services are created, they can be combined into more complex services, apps, or cross-functional business processes.
Consume – That functionality them made available for access/consumption by other IT systems and end-users.
Expose
The expose phase of the SOA approach focuses on which services to create from the underlying applications and data. Service creation can be fine grained (a single service that maps on to a single business process, such as ‘insert part number’), or coarse grained (multiple services come together to perform a related set of business functions, such as ‘process purchase order’).
The expose phase is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though use of an adapter.
Compose
Once services are created, they can be combined into more complex services, applications or cross-functional business processes. Because services exist independently of one another as well as from the underlying IT infrastructure, they can be combined and reused with maximum flexibility. And as business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications.
Consume
Once a new application or business process has been created, that functionality is made available for access (consumption) by either other IT systems or by end-users. By creating composite applications that consume these services and processes, you deliver to the business new dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including web portals, rich clients, Office business applications, and mobile devices.
What’s Next? What Say You?
So, the outline says “Service Modeling” next and then a short lead into ESBs as a Long-Term SOA investment vs. Short Term, followed by Indigo? What say you dear readers? You want Indigo now? You want CODE? Or is this working? Its up to you.
