Sunday, May 3, 2009

Business Concepts and Business Types

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.

Friday, December 19, 2008

Value for Money (Quality is Free)

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.

Tuesday, December 9, 2008

Linked-In Group

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.

Saturday, November 8, 2008

Service Oriented Enterprise Architecture Framework (SOEAF)

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.


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.

Friday, October 3, 2008

Object Management Group (OMG) Technical Meeting in Orlando

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.

Tuesday, July 22, 2008

MODAF Version 1.2

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.

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.

Tuesday, July 15, 2008

Healthcare SOA Reference Architecture

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).