Sehmi-Conscious Thoughts : Capability Modeling

The Next Revolution in Productivity - Harvard Business Review Article Related to MSBA

asehmi — Tue, 27 May 2008 04:15:40 GMT

I got my monthly issue of HBR this weekend and was really pleased to see the article "The Next Revolution in Productivity" by Ric Merrifield, Jack Calhoun and Dennis Stevens. For those of you who've followed my posts on Business Architecture and Capabilities, this article will be a welcome and easy going read with a strong connection to MSBA, though the terminology used is a little different.

The article makes strong points that "most companies that have embraced SOA have applied it without first rethinking the design of their businesses. This omission means they have overlooked SOA’s greatest value: the opportunity to create much more focused, efficient, and flexible organizational structures." And that "few companies are using SOA to create more productive and focused organizations or to slash costs by purging duplicative operations and technologies. They are not revisiting the fundamental design of their operations."

The idea of plug-and-play businesses is mentioned several times and builds upon an understanding of how new operating models can be developed from some key classes of capabilities or activities:

primary - i.e. core capabilities in MSBA terms - are activities that constitute the core competency of a company.
shared activities are re-useable across divisions.
shifted - i.e. outsourced capabilities in MSBA terms - are activities that can be performed by or transferred to a third party including partners, specialists and even customers.
automated activities are capabilities implemented as software services that can be incorporated into a SOA.

The article doesn't address what I see as a challenging gap between a capability definition and what you actually implement as a service in a SOA. The authors' use of the term activity rather than capability made it sound (to me at least) plausible if not easy to implement services in a straightforward manner provided activity analysis has been performed thoroughly. Getting to processes is then just a logical next step. But, having said this challenge is more or less glossed over, it's acceptable to omit tough technical design issues like this in HBR given its business-oriented target readership. The most important point that good SOA begins with good business architecture design and can lead to great improvements in productivity is made very well and with some great case studies too.

Finally, this paper is definitely worth reading and you ought to mail it to your CxOs immediately.

Mexico Regional Architect Forum 2008

asehmi — Sat, 03 May 2008 18:27:32 GMT

Last week I had loads of fun delivering a CCR-DSS-Robotics presentation at the Mexico Regional Architects Forum (RAF) in Mexico City. There’s something wonderful about this technology that set many people abuzz and I had some great conversations and brainstorming with some customers over drinks at the evening cocktail party. I find there's a very strong connection to enterprise scenarios and I gave a number of examples of how CCR-DSS could be used in common enterprise situations. I only hope we can get permission to publish some of our internal case studies on how some big enterprise customers are using this stuff in pretty impressive ways.

Many thanks to Vlad Vinogradsky; Marc Mercuri; George Chrysanthakopoulos; Henrik Frystyk Nielsen and Charles Liptaak for their material which I mashed together! Vlad did a great job putting together a compendium of samples that illustrate the basics of programming against the CCR which was extremely useful. To gain the most out of it, you must read Jeffrey Richter's MSDN magazine article on the CCR.

I also did a keynote presentation on Business Architecture and explained some of the recent fine-tuning being made to the MSBA methodology and I was able to demo a prototype of the new SQL-backed MSBA Entity Modeling Tool and Repository which replaces the unwieldy Excel-based heat maps and repository. My thanks here go to Mike Lloyd of Carbonflame who came up with a pretty neat Flex Index which helps contrast Capability models to Organizational Hierarchies, Process Optimisation and IT Infrastructure models. (Mike has been a long time proponent of MSBA since the days it was referred to a Microsoft Motion.)

I want to say what a pleasure it was for me to be in Mexico City which I thought was fabulous even though I saw very little of it. The food was superb and quite different to the commercialised Mexican food I have experienced in Europe and USA. The people I met are so easy going and friendly. Juan Lozada Villas, the D&PE Director, treated the RAF speakers to an evening at an authentic and apparently famous Mariachi restaurant (I think it was called Tarana?) which was awesome! I had an excellent education in Tequila from Jesus Hernandez Sanchez and tasted a number wonderful varieties. My favourite was Jose Cuervo 1800 Anejo and the Reposados generally... I bought three bottles at the airport Duty Free!

One last thing... Feliz Cumpleaños to Eduardo Nava Malagon! Sorry we didn't manage to sing to you during the keynote!

UPDATE - Business Architecture Resources (MSBA / Motion)

asehmi — Mon, 03 Mar 2008 20:52:12 GMT

** = Update

The Microsoft Services Business Architecture (MSBA) methodology was formerly codenamed Microsoft Motion. I will continually add to this list over time!

** Getting Hold of MSBA

Many people have asked me how they can get hold of the tools and detailed methodology documents for MSBA/Motion and were wondering why we don't appear to have anything new published since 2006/2007. Does this mean Microsoft has abandoned MSBA? No, quite the contrary! MSBA is alive and well. MSBA is a strategic asset of Microsoft Services and is a very important competitive differentiator for our IT Architecture Practice. We use MSBA to connect more deeply with Enterprise customers and have found that it is a wonderful thing in driving stronger relationships with them - and the reasons for this are obvious.

MSBA is available to our customers through fee-based consulting engagements with Microsoft Services. Globally, we've sold 100+ Architecture Transformation engagements to major customers so far this fiscal year and this kind of momentum will ensure MSBA's continued healthy development.

You are free to use whatever information I have published on this Blog about MSBA and if you (or your organization) would like to use our tooling and other assets - like heat maps, repository, explorer, etc. - then it would make sense for you to to engage directly with Microsoft Services in your Country or local Microsoft Subsidiary and contract a qualified/certified MSBA consultant to work with you.

MSBA / Motion Overview

** Ric Merrifield and Jon Tobey (2006), "Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion". A short effort focused on explaining the business architecture approach, and using ideas and templates from MSBA (was aka Motion) to help prioritise and select projects.
Ric Merrifield (2006), "Business in Motion, Parts 1 & 2", ARCast Interview with Ron Jacobs.
Homann, Ulrich (2006), "A Business-Oriented Foundation for Service Orientation." Microsoft Corporation.
Arvindra Sehmi (2006), "Rock Your Business Architecture with Motion", TechEd 2006 Israel Presentation.

Capabilities to Services

Arvindra Sehmi and Beat Schwegler (2006), "Service Oriented Modeling for Connected Systems", The Microsoft Architecture Journal, for Part 1: Issue 7, January 2006 and for Part 2: Issue 8, April 2006. (PDF)
Ulrich Homann and Jon Tobey (2006), "From Capabilities to Services: Moving from a Business Architecture to an IT Implementation", MSDN Solution Architecture Center.
Martin Sykes (2007), "Make it so. Effective methods to communicate an Enterprise Architecture to people who don't understand IT", UK Architect Insight Presentation.

MSBA / Motion Engagements

MSBA / Motion Case Studies

C.H. Robinson

** Related Content

Irene Polikoff, Robert Coyne and Ralph Hodgson (2005), "Capability Cases - A solution Envisioning Approach".

This book presents two intertwined innovations that work together to better connect business challenges to technology enablers to improve the odds for success in delivering value. Much like Motion in spirit and goes deeper than Motion in the actual creation of the high level logical solution. I found this book connects many different problem solving and solution envisioning ideas and requires one to apply quite a strong abstraction filter to make sense of it.

Modeling Business Capabilities by Combining Services with Communication Patterns (5)

asehmi — Wed, 27 Feb 2008 00:38:50 GMT

In my previous post I examined the business transaction pattern is some detail and made the case for using the pattern to much better implement a capability as a service (capsule). In this post I will develop the connection between the three part model introduced in [SS06] and propose how it can be extended to support the modeling of communication patterns. This requires a richer expression of a "service contract" to include the interaction sequence required to communicate with the service in addition to the conventional WSDL contract. The recent emergence of new technologies such as Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) present some interesting options for automating the generation of the conversation controllers necessary to support the service interaction.

Extending the Three Part Model

Traditional approaches to developing IT solutions frequently focus on two well-understood models—the business model which describes what the business does, and the technology model which describes one way of implementing the various business functions, as shown in Figure 4. However, this strategy frequently leads to close-coupling between the two models, resulting in dependencies between the technology model and the business model. This can cause brittleness if the business model changes, and can ultimately require that the technology model (and the implementation of the solution) be completely redeveloped as business circumstances change.

The prime reason for this is that Business and IT maintain their separate models within their respective domains. Business needs are conveyed largely by "tossing documents over the wall" – all too often confusing requirements with solutions. This has made IT adopt a very introverted view of itself, focusing on improving things that IT knows best, like availability, security and productivity, and not spending too much time contemplating how it can drive radical business change and add business value. IT solutions and platforms create technology silos that impose awkward constraints on the business model and as a result, business silos become reinforced by technology silos, and the whole system of Business plus IT becomes inflexible and arthritic - i.e. close-coupling. Thus Business and IT must work together to achieve common aims, but this is just not happening smoothly enough.

Figure 4. Traditional approach to modeling solutions

The Three Part Model attempts to eliminate as many of these dependencies as possible, enabling you to build solutions that can easily adapt as the business evolves and grows. It achieves this by introducing the Service Model. The service model enables you to abstract the business capabilities into one or more services, and then map these services to the technology model, as shown in Figure 5.

This simple idea lends a lot of value to the SOA vision which seeks not just to remove the gap between Business and IT but to blur the boundary between business processes and technology services. Essentially, SOA benefits by introducing the third service model element lying between the existing business model and the technology model. You might think that adding an intervening layer moves these models further apart, but actually the service model (and by implication, SOA) acts as a lubrication layer that allows the two models to flex and work together in greater harmony.

By imposing an intervening service layer, the business can focus strongly on defining levels of service rather than how those services are delivered. IT can in turn focus strongly on meeting contract obligations, choosing the best technologies and solutions for the circumstances, without unduly constraining the business process model. SOA naturally breaks down monolithic applications into finer-grained services which are more easily flexed and which can eliminate duplication. They are more easily aligned to business processes and help eradicate silo-based thinking. As a result, IT has to develop a much more outward-looking view. Instead of being led by the business IT strategy is driven by business needs. The promise of SOA is that it will lubricate brittle and static relationships and allow revitalized and agile businesses to gain a strong competitive edge.

Figure 5. Using the Service Model to remove dependencies between the Business and Technology Models

Using a service model facilitates discovery of services—the pieces of functionality implemented by the business—independently of any particular technology.

In Service Oriented Architecture terminology, the business capabilities identified by the business model have a very close correspondence to service contracts defined by the service model. Similarly, the business expectations (expressed as SLEs) translate to SLAs when the services are ultimately built and deployed, and so influences the choice of technology used to implement the services. For more information on the Three Part Model, refer to [SS06].

Describing Business Processes in the Service Model

However, breaking the business model down into a series of services only captures the business capabilities (what the business does), but does not provide information on the business processes that use these capabilities (how the business operates). To capture process information, the service model also needs to encapsulate how information and data flows between the various services. This requires extending the service model to include an orchestration mechanism that concisely and completely describes the way in which services interact, how they perform transactions, and how control passes between them. This in turn demands a mechanism to more richly express the definition of a service contract to include the message exchange patterns and the protocols that define the sequence of messages sent to and from the service.

While the structure and schemas of messages sent to and from the service can be adequately expressed by using WSDL, flow control is outside the scope of WSDL. Modeling this aspect requires either extending WSDL to include these semantics, or developing an additional WSDL-like grammar that can describe this information. This is the purpose of the SOAP Service Description Language—SSDL [SP01].

Like a WSDL contract, an SSDL contract defines schemas for describing data structures, messages, and endpoints. However, SSDL provides the basis for a range of protocol description frameworks extending those available in WSDL, including:

The Message Exchange Patterns (MEP) framework representing the common, simple message exchange patterns available in WSDL (one-way, request with single response, request with multiple responses, and so forth).
The Communicating Sequential Processes (CSP) framework, which enables a service contract to define multi-message interactions as a sequential process. CSP can describe systems in terms of processes that operate independently, and interact by passing messages to each other. CSP allows services to be defined both as sequential processes, and as the parallel composition of more primitive processes.
The Rules-based SSDL Protocol framework, which uses Boolean expressions to specify the messages that a service can send and receive in response to other messages, according to the current state of the service. For example, a merchant service should only expect to receive a payment message after it has sent an invoice message, and not before.
The Sequencing Constraints Protocol (SC) framework, which can describe complex, multi-party, multi-exchange sequences of messages with flow control, using a notation based on pi-calculus.

SSDL is currently a work-in-progress. The intention is to promote the development of tools such as model checkers that can verify the correctness of protocols defined in an SSDL contract and assess the compatibility of services, and also to enable hosting environments to validate the messages exchanged by services.

The Role of the Conversation Controller

A service host provides an environment for receiving messages and forwarding them to service instances, and for transmitting responses from service instances. The technology used to create the service host depends on the SLA requirements, the underlying network protocols, and a raft of other technological considerations. In addition, conversational services require hosts that can implement and enforce the rules governing the message exchanges defined by the SSDL contracts specified for those services. This leads to the requirement for the service host to incorporate a conversation controller component.

The conversation controller is essentially a state machine that drives the interactions with the services. Current SOA technology, such as ASP.Net and WCF, provide tools that can analyse a WSDL description of a service and automate the generation of code that can send and receive messages to and from a service. The next goal is to extend this notion and add a capability to generate code that automatically controls the flow of messages, according to the semantics defined by an SSDL description.

Automating the Conversation Controller

To briefly recap, to automate the generation of a conversation controller that can automatically handle the desired message exchange pattern required to communicate successfully with a service you need to know two things:

The schema of the messages sent to and received from the service. This is generally available as WSDL metadata.
The required conversation protocol. This defines the set and sequence of messages required to communicate with the service. WSDL does not convey this information and a different set of metadata such as that prescribed by SSDL is required.

The availability of tools for generating code from an SSDL description is currently very limited. However, Microsoft Windows Workflow Foundation (WF) and Microsoft Windows Communication Foundation (WCF) provide technologies that we can use to implement an alternative approach to define the conversation protocol. This approach uses a workflow to model the service message interaction rather than an SSDL description. It is possible to introspect the workflow metadata to derive behaviour metadata (also in the form of a workflow) that a client can use to control its conversation with the service.

The high level architecture of a prototype solution based on WF and WCF is shown in Figure 6.

Figure 6. High Level Architecture

The main components of the prototype solution are:

A state machine WF workflow exposed as a WCF service. The workflow implements the business logic for the solution. The workflow contains custom receive and send message activities in addition to regular activities used to coordinate the service's internal implementation logic. This workflow acts as a substitute for the SSDL description of the service.
A custom WCF service host called WorkflowServiceHost. The state machine workflow is hosted by a custom WCF service host. This is used to dynamically generate the service implementation based on introspection of the hosted workflow.
Custom workflow activities to send messages and to receive messages. These activities (SendMessage and ReceiveMessage) are part of the WorkflowServiceHost implementation.
Auto-generated behaviour metadata that models the required message interaction. The prototype implementation outputs a XOML-based sequential workflow. It consists of the activities, ReceiveMessage and SendMessage, contained in the state machine workflow but does not include any other activity that might be used as part of the service's internal implementation. In this way, the XOML generated workflow is used to model the message interaction behaviour required to successfully communicate with the service.
A client consumer of the WCF service. The client can use the behaviour metadata (the XOML workflow) emitted by the service to direct the desired sequence of messages that must be sent to and received from the service.

[ Note: I know that the above prototype solution probably ought to be re-implemented in .NET 3.5 using the new Workflow Services. No time on my hands unfortunately. Volunteers always welcomed! ]

References

[SS06] A. Sehmi and B. Schwegler, Service Oriented Modeling for Connected Systems, Microsoft Architecture Journal, for Part 1: Issue 7, January 2006 and for Part 2: Issue 8, April 2006.

[SP01] SSDL – The SOAP Service Description Language at http://www.ssdl.org.

I'll develop this topic in more detail in subsequent posts. Please come back or subscribe to my RSS feed.

TechEd Developers - 05-09 November 2007, Barcelona, Spain

asehmi — Sat, 03 Nov 2007 19:15:09 GMT

ARC01-IS Capability Mapping: A Foundation for Service-Oriented Architecture

Next week I'll be in Barcelona at TechEd: Developer to present the same interactive session I did at TechEd US 2007.

Please join me and come over to say hello - I very much look forward to seeing you on Mon Nov 5 17:45 - 19:00 Room 114.

P.S. I'll have plenty of A3 size posters of the Capability Mapping process to give away. At TechEd USA I totally underestimated the demand and ran out of them!

P.P.S. Interactive sessions are supposed to be small intimate affairs for up to 50 people, but I hear 300+ people have put this session into their agenda planners! That's amazing. This subject is really hot. Anyway, though our organizers have assigned a big enough room to seat this many people, I fear "interactivity" may suffer a lot. Nevertheless, you can be assured I'll try my best to make you feel involved!

Modeling Business Capabilities by Combining Services with Communication Patterns (4)

asehmi — Wed, 18 Jul 2007 15:04:00 GMT

In my previous post I looked at the communication patterns supporting the mutual interactions and coordination between services. Here we'll take a brief tour of the DEMO methodology [RD99] which, as we heard previously, builds upon Searle’s Language/Action...(read more)

Modeling Business Capabilities by Combining Services with Communication Patterns (3)

asehmi — Mon, 25 Jun 2007 08:17:00 GMT

In my previous post I talked about encapsulating capabilities as services with communication patterns supporting their mutual interactions and coordination - the so-called service capsule . In this post I'll explore communication patterns in more detail...(read more)

Business Architecture Resources (MSBA / Motion)

asehmi — Sun, 24 Jun 2007 19:03:00 GMT

The Microsoft Services Business Architecture (MSBA) methodology was formerly codenamed Microsoft Motion. I will continually add to this list over time! MSBA / Motion Overview Ric Merrifield (2006), " Business in Motion, Parts 1 & 2 ", ARCast Interview...(read more)

Modeling Business Capabilities by Combining Services with Communication Patterns (2)

asehmi — Sun, 24 Jun 2007 13:05:00 GMT

Introduction In my previous post I introduced the idea of a Service Capsule . Now I want to dig into the rationale for this kind of service component or concept. There are those that believe, and I am certainly one of them, that business models are essential...(read more)

Modeling Business Capabilities by Combining Services with Communication Patterns

asehmi — Sun, 24 Jun 2007 11:29:00 GMT

Starting with this post I'd like to delve a little deeper into the ideas I first started discussing in my talk entitled: " Service Capsules: A Language and Patterns Perspective on Service Design and Implementation ". I first became interested in Speech...(read more)

Content for my TechEd US 2007 Talks

asehmi — Fri, 22 Jun 2007 13:38:00 GMT

Capability Mapping: A Foundation for Service-Oriented Architecture (ARC09-TLC) Service-Oriented Architecture is a very interesting concept to many, but until it is clearly linked to business needs its rate of adoption is likely to be slow. This challenge...(read more)