SOA: Making the Paradigm Shift Part 8 of N

I have taken a bit of detour the last few episodes, and in this eighth one, I am going to get back to the world of Capabilities and Microsoft IO, App Plat IO, ESOMM Maturity Model and how Service Enablement Fits In. For a reminder, the series so far is:

Please note that some of this material is based on Microsoft provided material to partners. Also, note for disclosure purposes, my company Neudesic, is such a Partner offering Microsoft IO services. However, this post and this series is designed to be purely educational and reflect the presentations I give to INETA and general developer audiences, not marketing.

In Part 6, I talked about building a Capability driven strategy and being practical on bringing in SOA into current projects.

Microsoft Approach to SOA

More and more businesses are betting big on SOA to deliver against key business imperatives.  With SOA, companies can become more agile and flexible choosing what services to expose, build a business process around it and deliver it (consume) across applications, platforms and devices. 

Service Enablement is a powerful way for companies to transform their existing array of heterogeneous, distributed, complex and often inflexible IT systems into a set of more connected, simplified and adaptable ones that can better support the business. Service Enablement is not just a technology and architecture discussion however; it begins with a focused understanding of the underlying business needs that are to be addressed. It then takes a pragmatic, and often incremental approach to delivering business value through Service Oriented Architecture- centered around gaining greater business agility across existing IT investments by connecting disparate data and systems into new, higher-order services. Also key to this process is ensuring alignment between business goals and it’s key market differentiators are reflected in IT’s core investment priorities and projects. This will enable greater impact of the pragmatic SOA approach to be gained for business results.

As more and more IT components are exposed as services and orchestrated into processes that support the business, an internal service orientation (or “Enterprise Service Bus”) is established. From there, new services can be defined, added and published to support business scenarios as required. This in turn gives the company tremendous agility when looking to roll out new capabilities as there is much higher connectivity, discoverability and re-use of IT components – information flows according to the business processes and needs. 

Pragmatic, real-world approach to SOA that drives business value

While the benefits of SOA – better connections between disparate IT assets across business processes and enabling the delivery of dynamic (composite) applications to meet new business scenarios – are enticing, SOA implementations have too often failed to deliver the expected business results. Microsoft’s approach to SOA is focused on enabling customers to take a pragmatic, controlled path to service enablement based on gradual extension and augmentation of existing, heterogeneous assets. Driven by strategic vision and business needs, incremental, iterative SOA projects tackle business goals one need at a time, in ways and at a pace that are appropriate to the individual organization.

Key to this real-world SOA approach is to begin with a core understanding of the underlying business issues and IT scenarios needing to be enabled. It then focuses on creating wrapping required IT components with web services (“exposing” underlying data and applications relevant to the in-scope business issues), aggregating these services according to business processes and needs (“composing” more complex services or cross-functional business processes that are uncoupled from the underlying data and applications), and finally making them available to business users (“consuming” via composite applications - often web portals, rich client applications, mobile device applications etc.).

Ok, so a good question you may have right now is how? How do I get there? How do I organize my IT around Capabilities? That is what Microsoft IO is all about.

Microsoft Infrastructure Optimization (IO): A Capability Framework

Microsoft IO provides a Capability Framework to help you build an optimized infrastructure, and is based on three models. None of this was build in isolation. Microsoft worked with industry analysts, industry and academic experts to devise a set of models that establishes a foundation for where you currently are and where you may want to go to come into alignment with your business goals and capabilities, thus creating a Roadmap for a Dynamic and Agile IT, that focuses on delivering core business value rather than being a cost center. IO provides guidance and best practices for a step by step implementation.

Infrastructure optimization—centered on using an organization’s IT assets to support and advance the business—helps businesses measure their level of infrastructure optimization and drive for a truly people-ready infrastructure. Microsoft has developed three models—focusing on core infrastructure, business productivity infrastructure and application platform —that outline a progression through four stages of infrastructure optimization and that can lead to a roadmap for infrastructure maturity. Each of the models illustrate the strategic value and business benefits of moving from a “basic” stage of optimization, where the IT infrastructure is generally considered a “cost center,” toward a “dynamic” infrastructure, where the business value of the IT infrastructure is clearly understood and is viewed as a business growth enabler and strategic business asset. Using these models, you can gauge the current stage of the infrastructure, establish a technology vision for the future, and build a clear roadmap to achieving that vision.

IO is focused around three models:

1. Core – Fundamental IT Functions
2. Business Productivity – IT Functions to improve overall business productivity. This area is business focused.
3. Application Platform – IT functions to improve IT’s delivery to the end business user. This area is somewhat focused on development.

All of the Models contain 4 “Stages” or “Levels of Maturity.” I like to look at these as helpful ways to figure out where you are in terms of YOUR capabilities and goals, not to be used as a “bad thing.” When I first looked at IO, I was quite concerned about CMM. I don’t see IO as having anywhere near the ceremony and stigma of CMM. I see it as an honest appraisal of where you are. In other words, it’s quite foolish to just say “let’s do some SOA.” Many companies do that and they fail. On the other hand, if I use IO and figure out where does Service Enablement fit into MY context, my capabilities, my business needs then it’s a more honest and organic process. That’s the subject of the next section, App Plat IO.

Application Platform (App Plat) IO

I could write volumes about IO but the chief area I am interested in is App Plat IO, in order to help move from disconnected applications and services (including JBOWS) to SOA and Adaptive Business Processes.

In pulling out SOA and BP, it turns out that there is a 1-to-1 mapping with an earlier model called ESOMM – The Enterprise Service Oriented Maturity Model. ESOMM was described in a Microsoft Architecture Journal article, “

All 4 layers, 3 perspectives, and 27 capabilities defined in the ESOMM are designed as a road map to support services—not any specific service with any specific use, implementation, or application, but any service, or more specifically, any set of services. If you intend to develop only one service, the value this model provides will be limited. The objective of ESOMM is to help you overcome the problem of scalability at a group, department, division, or enterprise level. This objective means it can be applied as part of a grassroots initiative or an enterprise strategy. Your ability to provide certain capabilities might be limited by the extent of your overall organizational alignment, but that factor should not impede your ability to start building and implementing a plan leveraging ESOMM.”

In terms of concerns with CMM, they take a decidedly practical approach,

“Like other maturity models, ESOMM was derived from Carnegie Mellon's Capability Maturity Model (CMM, see Resources). However, we borrowed the notion of a capability-driven maturity model and stopped there. Instead of applying service orientation to the CMM, we took those principles and applied them to the service-orientation paradigm, essentially building the road map from scratch. This model does not focus on processes because the focus is on IT capabilities, not organizational readiness or adoption. While you will recognize some conceptual similarities with CMM, you can also see that ESOMM is a decidedly different application of the maturity model concept.”

Please see the article for more information as well as the IO Materials.

This makes it clear that SOA is a journey. We may start in Basic with a bunch of JBOWS and that may be barely useful. As we incorporate clear SOA capabilities and best practices like Common Schema, Versioning, Discoverability, Auditing, Governance, we move from just JBOWS to an SOA, which is dynamic and agile for the business needs.

There is also Methodogy and Architecture to help us get there. This is what I like to call '”putting the A in SOA.”

During this journey we may move from basic disorganized services, and locked-up business processes inside standalone and proprietary apps and being totally reactive to one where we not only have well-defines services but the ability to aggregate those services beyond the firewall. We move from hand-coded, phone, fax business-to-business communications to automation to B2B workflow services with end-to-end visibility.

So, let’s look a little bit and how we specifically do this. Please realize that the following with be different for each company and their journey.

Next

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. Middle-Out SOA is the topic for next time as we get closer to Indigo.