SOA Process

Business Concepts and Business Types

2009-05-03T11:16:00.004+01:00

One thing I keep getting asked why the CBDI Service Architecture and Engineering method distinguishes between the Business Concept Model (describing things as they are in the real world) and the Business Type Model (describing things as they are represented within the enterprise systems).

Here's a simple example. As I mention in my post Will Libraries Survive? there is a conceptual difference between book title and book copy.

"Some libraries identify each physical copy individually, while other libraries merely count the physical copies of a given book title. The physical copies are distinct in the real world, but may be indistinguishable in the library systems. Information strategy includes making this kind of choice."

Let's suppose a library buys ten copies of a book. To start with these copies are physically indistinguishable. The library then attaches some identifying marks to the book, including an ID number. This marking depend on the information strategy - the library could choose to give all ten copies the same number or could choose to give each copy a different number.

If we assume that this id number is used throughout the library systems, then it is clearly important to know whether the id number identifies the book title or the book copy. So this is a critical element of the Business Type Model, which reflects a whole series of strategic decisions of this nature, and then feeds into the identification of core business services.

One important form of business improvement is to increase the differentiation in the Business Type Model. For example, a library that previously didn't distinguish between physical copies could decide to make this distinction in future. But this business improvement doesn't change the underlying reality of books, so the Business Concept Model stays the same.

I shall be writing up some more complex examples for the CBDI Journal and eLearning.

Value for Money (Quality is Free)

2008-12-19T13:12:00.003+00:00

The Service Architecture and Engineering methodology includes a discipline called SOA Adoption and Excellence.

Our idea of excellence is based on standard frameworks of total quality management, in particular the excellence criteria embedded in TQM competitions such as the Baldrige Award or the European Quality Award. In these frameworks, you don't score points for investing in quality for the sake of quality; you score points for having clear visibility and measurability of cause-and-effect: how is this capability or resource contributing to these positive outcomes. If you do it properly, TQM should produce an organization that is highly efficient and effective, because all the capabilities and resources of the enterprise are focused on achieving tangible results. In other words, we can think of these frameworks as value-for-money frameworks.

The slogan "Quality is Free" was invented by Philip Crosby, one of the gurus of the TQM, and is the (provocative) title of one of his books. Many people explain this by turning it around: lack of quality is expensive, because it leads to rework, wasted or underutilized assets, customer complaints, high staff turnover, and many other costs.

So the emphasis in our approach to SOA capability planning is to identify those capabilities that will have the greatest impact on positive outcomes, identify the key dependencies between capabilities, and focus the limited resources of the enterprise on just-in-time acquisition of the most critical capabilities. If this isn't value-for-money SOA, I don't know what is.

Linked-In Group

2008-12-09T09:25:00.002+00:00

The CBDI Forum has started a group on Linked-In.

For those of you that don't know, LinkedIn is the largest social network geared toward professionals, with over 30 million members. I've found it to be a great way to find colleagues with similar interests, as well as reconnecting with old friends and colleagues.

Click here to join.

We're hoping to get some lively discussion going on the SOA Process and related topics. Of course, we'll still be putting things on this blog from time to time, so please stay subscribed. And check out the CBDI group on SlideShare as well.

Service Oriented Enterprise Architecture Framework (SOEAF)

2008-11-08T16:33:00.010+00:00

As a member of the Open Group SOA Working Group*, Awel Dico has produced various working papers about incorporating SOA into TOGAF.

In his latest blog posting, he offers a diagram proposing a service oriented enterprise architecture framework (SOEAF). This diagram focuses on SOA-based solutions, and I guess this is similar to what people sometimes call Service-Oriented Business Applications (SOBA).

This diagram has a fair amount in common with the CBDI Service Architecture and Engineering approach, but there is one important difference. At CBDI, we have long championed a twin-track approach, separating the architecting, provisioning and operation of reusable services from the architecting, provisioning and operation of service-based solutions. I don't know how this kind of twin-track approach could be accommodated in the SOEAF framework.

Update

Unfortunately, Awel's blog has been affected by a serious security problem, so I have moved the diagram and removed the links. Hopefully this will be resolved soon.

Object Management Group (OMG) Technical Meeting in Orlando

2008-10-03T16:16:00.007+01:00

As some of you may know but many probably don't, Everware-CBDi is intimately involved with the work going on within the Object Management Group (OMG). This is an industry group that has standardized such things as the Common Object Request Broker Architecture (CORBA) and the Unified Modeling Language (UML), and coined the term "Model Driven Architecture" (MDA ™). Last week the Object Management Group (OMG) held a week long Technical Meeting in Orlando, FL. It was quite an interesting meeting with a number of rather notable events. Below is a brief summary of some of these events. Please take note that there are many parallel meetings taking place at any one time and since I'm just one person, items that some might find valuable were surely missed. With that caveat, here goes:

UML Profile and Metamodel for Services (UPMS): This is an area where Everware-CBDI has been particularly active. We're part of a submission team with numerous other large and small organizations from around the world. The team has put forth a revised submission (the equivalent of a draft standard) to the Analysis and Design Task Force. However, due to a number of changes that came up subsequent to the submission but prior to the meeting, we’ve extended the submission date to the 4 week rule for the December meeting in Santa Clara, CA. Here are the two major changes from the Everware-CBDI perspective (note: the descriptions below are for UML devotees):

Change "Service" to "ServicePoint": The original thought on the team was to create a stereotype of Port for Service. This would mean that one would not be able to model what we refer to as Services without Participants (the things that offer the Services in the UPMS parlance). It would also mean that a Service is a kind of "access point" (to interpret UML) instead of the generally accepted view that a Service is a capability made available to a consumer. Upon further reflection, the "access point" didn’t make sense to the team. Though we were not initially sure what the alternative would be, we finally agreed to change that stereotype name to "ServicePoint" since this is the point at which the service is accessable. The result of this change is that there is no longer a singular element called "Service". However, the team agreed that this might actually be a benefit given that there are so many slightly different definitions thereof.
Change "ServiceCapability" to "Capability": We also decided to change the name of the element we called ServiceCapability to just Capability. ServiceCapability is the element that most closely resembles what Everware-CBDI has referred to as ServiceSpecification. We believe this makes sense because it allows us to specifically model Capabilities and relate them to ServiceInterfaces (Capabilities are accessed through ServiceInterfaces at a ServicePoint). Further, we can now say that Participants realize Capabilities. Since Participants can be organizational units, automation units, infrastructure nodes, etc., we now have a parallel mechanism for modeling capabilities of these elements and creating services to get at those capabilities. Further, this model is now compatible with the proposed standard for a Unified Profile for DoDAF/MoDAF (UPDM) that is currently out for comment. Everware-CBDI this will be a slight change but it will be relatively easy to incorporate and as stated earlier will provide a relatively standard way to model Capabilities.

Executable UML Submission Adopted: A revised submission for executable UML was accepted by the ADTF and Architecture Board. Named fUML for “Foundational UML”, this is work that has been driven primarily by Steve Mellor and Ed Seidewitz and supported by many others for the past 10 yrs or so and has finally been voted through. Executable UML potentially represents a major breakthrough in the way systems, particularly embedded systems, are built and could be the basis for the next generation of MDA tools. This standard is being closely followed by an RFP for a concrete syntax for a UML Action language. The responses to the Action Language RFP will provide a standardized concrete syntax for the executable elements of UML.

Unified Profile for DoDAF and MoDAF (UPDM) RFC Issued: For those not familiar with all the acronyms let me fill in the blanks. “DoDAF” stands for (US) “Department of Defense Architecture Framework” while “MoDAF” stands for (UK) “Ministry of Defence Architecture Framework”. The “RFC” acronym stands for “Request for Comment”. What this means is that the UPDM submission process has been changed from the more common “RFPSubmissionRevisionAdoption” process to one that is normally applied to what is considered an industry defacto standard. The RFC process essentially boils down to taking an industry standard, issuing a Request for Comment on the standard and if no major issues arise, adopt it as an OMG standard. However, if any major issues arise during the comment period, it is rejected as an OMG standard. This is the process that the OMG used to adopt the Business Process Modeling Notation (BPMN) as an OMG standard.

The thing that is remarkable in this case is that one would be hard-pressed to say that UPDM is an industry standard so let me provide some background. Much work has been going on to create a submission for the UPDM RFP that was issued by OMG some years ago. At the March meeting in DC, there was major disagreement among the submission team about the direction of the submission. Chaos ensued.

Normally, that would kill the standard. However, everyone realized the importance of this standard to all parties and so DoD and MoD decided to just go the RFC route by taking the submission and turning it into an RFC. As issued, UPDM targets DoDAF 1.5/MoDAF 1.2 support. While some in the meeting suggested that it’s not ready and there’s not enough time to thoroughly review and provide comments by the 4 week rule for the December meeting (November 10), when it came to the vote, it passed 22 for, 0 against, 2 abstains.

My suspicion is that those that were initially opposed to this form of the submission will log a number of significant comments – more than what would typically be allowed for an RFC to pass. The Architecture Board will then have to decide how to get the changes made and incorporated. I believe that since DoD and MoD are such big customers, no one will want to be seen as opposing them and so the concerned parties will work to compromise and resolve the issues.

MODAF Version 1.2

2008-07-22T14:12:00.003+01:00

A new version of MODAF has just appeared, which puts MODAF firmly ahead of other enterprise architecture frameworks in terms of its support for SOA.

MODAF is the enterprise architecture framework produced by the UK ministry of defence. Version 1.1, which appeared last year, contained a Strategic View, described in terms of Capabilities and Capability Dependencies. Version 1.2 now contains a Service (or "Service-Orientated") View, driven by the Strategic (Capability) View, and sitting above the Systems View.

http://www.modaf.org.uk/

This clearly goes further than the latest version of DoDAF (a roughly similar framework produced by the US Department of Defense), which has a single view for Systems and Services, and no Strategic View.

Meanwhile TOGAF remains stuck in a time-warp. In December 2003, when I wrote an article on Enterprise Architecture for the CBDI Journal, I was told that TOGAF 9, which would have some support for SOA, was "coming soon". Nearly five years later and it is still "coming soon". Soumen Chatterjee expects that "too many players" will produce a "mixed-up world".

There are a few bloggers talking about possible SOA support within TOGAF, including Raj Ajora and Awel Dico, and some good ideas coming out of the SOA Working Group within the Open Group. But they've got some catching up to do.

Healthcare SOA Reference Architecture

2008-07-15T11:12:00.003+01:00

I have just been looking at the HL7 and OMG Healthcare Services Specification Project (HSSP), which is developing an SOA Reference Architecture for the Healthcare domain, based significantly on the CBDI SAE metamodel.

The HSSP team is generalizing the CBDI meta-model to be able to specify non-SOA legacy software systems and their transition to a System of SOA Components (SoSC).

Architecture AND Engineering

2008-07-03T10:51:00.002+01:00

In the June 2008 editorial for the CBDI Journal, David Sprott talks about learning from other architectural disciplines - from the open plan building style and organic architecture principles pioneered by Frank Lloyd Wright to the incredibly innovative design of the Sydney Opera House.

David's editorial focuses on architectural style and patterns, but we can also learn lessons about process, and about the relationship between architecture and engineering. The Sydney Opera House is an amazing building, but its development was costly and troubled, and the relationship between the architect (Jørn Utzon, who had worked for Frank Lloyd Wright) and the engineering firm (Ove Arup) was a difficult one.

With SOA, we are not just interested in producing innovative structures (loosely coupled enterprise, layered service architecture, and so on) but producing these structures in an agile and cost-effective way. Architecture is not a stand-alone activity, but must be integrated into the engineering process. That's why we call the CBDI process Service Architecture AND Engineering.

UML Profiles

2008-06-05T04:54:00.003+01:00

A UML Profile is a mechanism that allows existing UML tools such as Sparx Systems Enterprise Architect, No Magic's MagicDraw and Rational Software's Rational Software Modeler to immediately begin using a language that extends the UML with additional semantics and notation in a standard, shareable manner.

The OMG is working towards a UML Profile and Metamodel for Services (UPMS). Meanwhile, here are some other UML Profiles of potential interest to the SOA and EA communities.

PGFSOA

2008-03-22T05:27:00.002+00:00

A Practical Guide to Federal SOA

Draft 1.0 Public Release Draft has just been published at the PGFSOA portal. You can read the draft online, download PDF and make comments at the PGFSOA wiki.

The document contains the following sections

Enabling The Mission
Executive Summary
Introduction
The Rationale for Federal SOA
Service Oriented Vision - the Target Architecture
Keys to Federal SOA Implementation
A Roadmap for SOA Adoption
Glossary
References
Examples

CBDI has provided a lot of input to this document. We hope it will be useful not just to Federal Government but across a much wider community.

Information Model Support

2008-03-14T21:40:00.003+00:00

I just received a private email with a suggestion to improve the SAE metamodel.

"I am approaching information management from the Information Engineering perspective. I am suggesting that the metamodel indicate the different users views or levels of data oriented models (Mission, Subject Area, Conceptual Logical and Design). These models serve different purposes in the Enterprise Architecture stack."

It's an interesting idea, and we shall consider it. However, we are conscious of the need not to overload the metamodel, so it may get excluded on those grounds. We are also keen to keep the metamodel as uncontroversial as possible. I am sure there will always be room for people (including ourselves) to differentiate themselves by adding local refinements.

TOGAF

2008-01-18T13:30:00.000+00:00

One or two people have asked about the relationship of SOA process to TOGAF ("The Open Group Architecture Framework"). This is an enterprise architecture framework,

I actually wrote an article back in December 2003, outlining some of the challenges faced by TOGAF 8 in embracing SOA.

TOGAF insiders told me then that TOGAF 9 would provide some support for SOA. Four years later and we are still waiting for TOGAF 9. (The current version of TOGAF is 8.1.1.)

However, there are signs that we won't have to wait too much longer. In July 2007, the Open Group published a white paper, outlining plans to embrace SOA within TOGAF. The white paper acknowledges CBDI as a source for these SOA plans, and we hope that the next version of TOGAF will contain a lot of CBDI thinking.

And of course we shall want to repay the compliment. Much of the SOA Process is based on widely used industry approaches, including TOGAF and Zachmann. When the Open Group publishes its guidance on SOA, we shall certainly want to further align the SOA Process with this.

In the meantime, we welcome further discussion about the process implications of SOA and EA in relation to TOGAF or any other EA framework.

Sources

Service Oriented Architecture Frameworks (CBDI Journal, December 2003)
Service-Oriented Architecture (SOA) (The Open Group SOA Working Group, July 2007)
The Open Group Architecture Framework (TOGAF) (Wikipedia)

Introducing the SOA Process

2008-01-01T17:08:00.000+00:00

In this blog we are making available a piece of work that CBDI has just completed together with TIBCO. The two parties have collaborated on developing a SOA Process Framework – which extends earlier CBDI original work to integrate solution and service architecture processes.

We are placing this work in the public domain and inviting comment and feedback. At this stage we have no particular agenda for standardization, but would welcome your feedback and thoughts a) on the process framework as a basis for better collaboration between parties in a service oriented federation – i.e eventually everyone, and b) the need for common understanding in the industry, and possible standardization.

Good Business Modelling and Decomposition

2007-12-11T10:12:00.000+00:00

In a comment to my earlier post, Vasu writes:

"I agree with the fact that SOA is hyped much more than what it actually deserves - the basic tenet that is put forward by industry and vendors clearly indicates that SOA process is no different from "Good Business Modeling and Decomposition" except that there is more emphasis on streamlining, standards and products (that adhere to these standards)."

I accept that much of the SOA process can be understood as "Good Business Modelling and Decomposition". But that depends what you mean by "Good". Common analysis and design practices that were good enough for pre-SOA may not be good enough for SOA, since any weaknesses or ambiguities in the models and specifications are exposed. Some useful short-cuts and optimizations that were acceptable or even encouraged in pre-SOA days (because they improved short-term productivity) are now revealed as anti-patterns, because they have a negative impact on interoperability and reuse.

So if you are looking at the SOA process at the high level, you may find many of the same tasks and techniques that you are already familiar with. But there are a lot of differences at the detailed level. How many of these are differences in substance rather than just differences in emphasis? Well, that depends what exactly you're comparing it with, but I think most people will find a lot of real substantive differences.

Finally, I'd like to respond to what you say about "industry and vendors". The vendors are of course interested in selling products to support SOA - software tools and platforms, etc. Any advice they provide on SOA process needs to be understood in that context. Of course they will emphasize continuity with the good software practices of the past, of course they will emphasize aspects of the SOA process that promote their own products, and de-emphasize aspects that don't fit with their own product strategy. There are some excellent insights in some of the vendor material, but don't expect to get a complete view of the SOA process from them.

But I would say that wouldn't I?

SOA Process Report

2007-11-30T14:05:00.002+00:00

A report on the SOA process by Paul Allen and Paul C. Brown has been published in the CBDI Journal for November 2007. This is a sequel to an earlier report by Paul Allen from February 2007. PDF copies are available for download (for a limited time only).

Architected Solution Delivery: Enhancing the Service Oriented Process (PDF: November 2007)
The Service Oriented Process (PDF: February 2007)

These reports are also available on the CBDI Forum website.

Architected Solution Delivery: Enhancing the Service Oriented Process (November 2007, available to all )
The Service Oriented Process (February 2007, available to all)

Paul Brown is the author of Succeeding with SOA and SOA in Practice. Paul Allen's most recent book is Service Orientation: Winning Strategies and Best Practices. For details of all their books, please visit the SOA Process bookstore.

SOA Process Framework

2007-11-30T10:37:00.000+00:00

Click here to download a large-format version of the SO Process framework (PDF format). Designed to be printed on a large piece of paper (A3 or similar).

Tell me the Truth about SOA

2007-11-22T11:57:00.000+00:00

In my time in the IT industry - longer than I care to admit - I have generally worked at the leading edge of new software technology - including relational databases, fourth-generation languages, CASE tools, business intelligence, open distributed processing (ODP) and component-based development.

There were difficulties with all of these technologies - both practical (people simply didn't know how to use them effectively, or were reluctant to make the necessary organizational changes) and rhetorical (vendors making wildly optimistic claims, provoking equally wild counter claims).

I sometimes wonder whether there really is more nonsense spoken about SOA than all of these previous technologies put together, or whether it is simply that the nonsense gets greater exposure nowadays (thank-you Internet, thank-you Google, thank-you Blogger).

Even on Wikipedia - often a surprisingly good source of simple information - the articles on SOA and related topics are complicated and confusing. See Wikipedia Category: Service-oriented (business computing). There are some industry models and standards emerging, but most of these are focused on the web services technology stack.

At CBDI, we have always regarded the process as more important than the technology. It isn't what you have that matters most, but what you do with what you have. I had another opportunity to argue this point recently in the pages of IEEE Software, in a debate with Donald Ferguson of Microsoft (formerly Chief Architect of IBM Websphere).

So what is the right process for SOA? We've been working on this for a good while now, and we've decided to make some of this material available through this blog, as a basis for broader collaboration across the industry. What we're hoping to do is open up a wide-ranging discussion about process - what are the problems that an SOA process needs to address, where does an SOA process need to direct the attention of SOA practitioners, and what is the body of knowledge and experience that an SOA process can draw upon?

I intend to return to these broad questions in future posts, and I expect other bloggers will have something to say as well.

SOA Process Issues

2007-11-21T13:47:00.000+00:00

Disjointed SOA is all too prevalent.

Business Process: There has been much marketing hype around BPM and SOA with very little substance.

Software Solutions: Too often SOA projects are isolated from the real world of software solution delivery.

Runtime Operations: Day to day software runtime management tends to be treated as something of an afterthought in most SOA approaches.

A common failure of software processes is that they do not enable good project and program management, because they are “closed” and task driven.

An improved SOA process needs to address the following issues:

Relationship and interaction between enterprise and project and program architects
Balancing solution and enterprise architecture
Achieving full life cycle governance

Architected Solution Delivery

2007-11-16T11:59:00.000+00:00

Updated version

| View | Upload your own

Contact Details

2007-11-14T11:48:00.000+00:00

by email: please contact soaprocess (at) everware (dash) cbdi (dot) com