Service Classification

Zapthink recently asked the question "Are Services nouns or verbs", and if they can be designed as either, then which is better?

I don't think it is a case of "which is better". Services that expose a process (verb) address different requirements to those that expose an 'entity' (noun) . One is not better than the other. Instead they complement each other.

In CBDI-SAE we classify services according to the type of capability they provide. By focusing each service on a particular type of capability it enables greater modularity, separation of concerns and so on, enabling them to be more easily shared or composed into new services.

For example core business services (entity) provide operations focused on managing the information about a key business resource - like customers, orders, or products. These are independent of the processes that use that information.

Whereas process services provide operations that enable solution assemblers for example to interact with the different steps in the process. In turn the process services then consume the appropriate core business services.

In this way they can change the process service, add new operations and such, or add new processes, but without impacting the core business services.

If you mix these capabilities together you run the risk for example that the entity information is only provided via a specific process. We see this often and it's just too coarse grained and not a very agile approach. Processes have a different change cycle to entities. Many different processes use the same entities. So keep them apart.

Suggesting, as some are, that there is only one type of service and each provides multiple types of capabilities overloads the service and makes it difficult to use or share in different contexts or solutions..

We go further than just verbs and nouns however, and CBDI-SAE classifies service types into Process, Capabilities, Core Business Services, Utilities, Underlying, and Infrastructure .

Appendix A1 of our CBDI-SAE Meta Model for SOA also provides definitions for each type, and also gives an example policy for dependency rules between service types.

In CBDI-SAE we then detail different techniques that are applicable to identifying and specifying each type of service.

SOA Manifesto – Good, but too late?

This week, a small group of SOA cognoscenti met and published a SOA Manifesto. Thought it is eloquently put, it is difficult to see what has been said in the SOA Manifesto that hasn’t been said before.

The reality is that SOA isn’t new anymore. That some claim it is in fact dead or passé is testimony to no matter how much advocates of SOA protest, we have failed to fully get the message across, at least to the business that is footing the bill. I am not sure how the SOA Manifesto changes that. Those that are already pre-disposed towards SOA will become signatories ( I already have); those who are not will ignore it. Little will have changed.

I am reminded of the current political situation here in the UK, where the current labour government could put anything they wish in their manifesto for the coming general election but they are so unpopular it wouldn’t make much difference. Even if they promised to abolish taxes, they still wouldn’t convert those who have already made up their mind how they are going to vote. (and when did any political party actually deliver on their manifesto?)

The world has moved on. SOA should be considered business as usual. Yes, organizations still need to improve the way they approach SOA . Yes, people still need to adopt and apply the principles and be provided with better guidance. But if you want to get the majority’s attention, then you need a manifesto that excites them about the coming decade, not one that tells them what they should have been doing better in the last.

As I highlighted in my blog on Architecture for the Smarter Planet, SOA is one piece of an architectural puzzle that is going to challenge enterprises and individuals over the next decade. Although I believe the future is intrinsically service-based, I know we are not going to convince organizations to invest by telling them all they need is SOA. Rather, SOA has to be put in context, and positioned as one part of something much bigger.

Something like the Smart Ecosystem seems a much more holistic topic for a manifesto that addresses the needs of the next decade. The challenge for businesses will be how they become successful participants in ecosystems they do not control. SOA plays an important part in that, and can be a key enabler in a genuine business vision.

But just saying that SOA should be “business driven” doesn’t make it so.

Architecture for the Smarter Planet

You are probably aware by now that IBM’s current ‘theme’ is the Smarter Planet.Their basic message is that organizations (both businesses and governments) should take advantage the fact that we live in a world that is,

• Instrumented – 30 billion RFID tags in supply chains
• Interconnected –Trillions of connected devices, and two billion people on the web
• Intelligent – 15 petabytes of new information created everyday

And to do something ‘smart’ with these resources.

This seems in part a reinvention of the ‘Pervasive Computing’ vision. I authored a lengthy report on this some time ago in 2002. I still don’t think we are fully there yet, but you can sense that we are another step closer to it becoming reality, and IBM provide some good real world examples via the link above.

Architecture Scope

Attending the IBM Rational Software Conference recently at which the smarter planet was the theme of the keynote, it prompted me to think about what sort of business and IT architecture was needed.

One thing that is clear is that architects need to think very carefully about scope in this scenario. You cannot take a narrow inward looking project or even enterprise-wide view when the smartness you seek comes from the interconnectivity and behavior of the ecosystem. My colleague David Sprott has coined the term Smart Ecosystem Architecture (SEA) in reference to this.

I believe the key thing here in relation to SEA vs EA (Enterprise Architecture) is for organizations to understand

• what activities are going to be performed by the ecosystem (or the other participants in it), and what activities they need to perform themselves.
• and consequently, what they have to do – e.g. in terms of service provision – to participate in the ecosystem, and hence what capabilities and resources they need to provide their services, and handle the events that require their response

It also seems critical to me to that it is necessary to understand which capabilities are core vs context, but from an ecosystem perspective. (I need to ponder on that further…)

Architecture Patterns

That addresses scope, but what about the architectural patterns that applies?
I am tempted to say it’s all about Service Oriented Architecture (SOA) – in that federated, interconnected ecosystems are inherently service-based. But smart behavior is in a large part about sensing events and responding to them, so we need to add Event Driven Architecture (EDA) into the mix.

Before long I recognized we need several other architectural patterns in support of the Smarter Planet. I started off trying to draw a layered architecture to support of this, but that seemed inappropriate, so for now I will try to sum it up in a simple textual list.
OK, so the architecture for the Smarter Planet involves

• trillions of connected objects and billions of people accessing petabytes of information via millions of solutions, based on an agile,
• Web 2.0 Architecture – enabling billions of people to mash up rapid, user and community driven solutions, in turn assembled from millions of services, and generating trillions of events,
• requiring Event Driven Architecture (EDA) to determine the autonomic response required to sensors and changes in state,
• that are also placed into context by Business Process Architecture (BPA/BPM) and Information Architecture (IA)
• supported by services in a Service Oriented Architecture (SOA) that provides a formal basis for the decoupling of Provider and Consumers resource,
• as well as a Web Oriented, or Resource Oriented Architecture (WOA/ROA) as exchanging information between those trillions of devices in an efficient manner will likely be done in a more lightweight manner than full blown Web Service-based SOA
• with the implementations defined in a Component Based Software Architecture (CBSA) - with the focus on right-grained software enabling federated software delivery, that is running anywhere, anytime on a
• Cloud Based Architecture (CBA) that details the virtualized, federated infrastructure providing scalability, reliability. Which brings us back to SOA, as cloud computing is inherently service-based.

Anything I missed? My point is that architecting for the Smarter Planet is not about choosing one architectural pattern in preference to another – SOA or EDA or WOA or Web 2.0. One of those can't possibly address all the requirements. But rather how to use SOA+EDA+WOA+Web 2.0+xyz together, and understanding how they relate, not compete.

Enterprise Architects will argue these are all just components of EA, and to some extent that is correct. However, the scope now needs to be broadened to SEA.

What we need to avoid is any sense that things just got more complicated thanks to the Smarter Planet. With the application of sound architecture, it ought to get a whole lot simpler.

Some of CBDI Forum's Architecture mashups,

• Extending SOA with Web 2.0 (free access on registration)
• Web 2.0 and Enterprise Architecture (subscription required)
• Event Driven Service Architecture (subscription required)

CBDI-SAE Meta Model for SOA Version 3

The September 2009 CBDI Journal contains a “draft” publication of Version 3 of the SAE Meta Model. It incorporates some changes based on our continued work with customers and standards organizations and provides a mapping to SoaML so that end users can reap the benefits of both the breadth and depth of the SAE Meta Model as well as the capabilities that tool vendors will develop based on SoaML. Everware-CBDI plans to publish mappings to other ontologies shortly and other meta models as they mature.

It’s been some time since the last major revision of the CBD-Service Architecture and Engineering™ (SAE) Meta Model for SOA. Since then Everware-CBDI has published a UML Profile for SAE1 that has received quite broad acceptance and has been downloaded by thousands of members worldwide.

Everware-CBDI is committed to aligning with standards where appropriate and to that end we have contributed to, and worked extensively on SoaML, the service modeling language developed within the Object Management Group (OMG). What we’ve found in the course of our involvement in these efforts is that while there is some convergence in terminology, significant differences remain in the details between the various standards bodies working in this area, ranging from overall purpose of model/ontology of each organization to the exact definitions.

Our intent in the SAE Meta Model is to provide support for these various standards to our membership while not sacrificing the value built into our existing meta model. To that end, we will provide mappings of SAE terminology to these various meta models, profile and ontologies and guidance regarding their use within SAE.

Background

The SOA marketplace continues to mature and at Everware-CBDI we feel a measure of satisfaction in knowing that we’ve had a hand in that evolution through the guidance we’ve been giving over the years. The SAE Meta Model is one of many contributions and was a key input to the Object Management Group’s SoaML specification.

The SAE Meta Model was first released in October of 2006 and updated to Version 2 in 2007 as a result of feedback from our membership and the broader industry. Everware-CBDI created a UML profile based on V2 in 2008 that has since been downloaded thousands of times all over the world. Obviously industry was ready for more mature support for modeling services and the feedback we got was very positive.

In parallel with our efforts the Object Management Group (OMG) issued a Request For Proposal (RFP) for a UML Profile and Meta Model (UPMS) in September of 2006. A submission team formed that included Everware-CBDI, IBM, EDS, HP, Model Driven Solutions, SINTEF and several others. SoaML was finally adopted as a specification in November of 2008 and is currently in the finalization process.

Introduction to V3

Any model remains a work in progress if it is to continue to be relevant over time. The SAE Meta Model is no different. As mentioned above the meta model has been downloaded thousands of times and has provided a practical mechanism for using SAE with existing toolsets. Feedback from that broad membership usage along with our own involvement in standards organizations and client engagements has pointed out some areas that needed improvement and some holes that needed to be filled. Equally, we have continued to refine and extend our SAE guidance. Hence, we saw requirements to address the following:

• Incorrect or cyclical dependencies between meta model packages,
• Only a very loose notion of who or what is providing a service,
• The need for a more consistent concept of Service for both business and software contexts,
• Separation of a concept (or “thing”) from the specification (i.e., the artifact) of the concept,
• The need for refinement of the relationships between Service, Automation Unit, and Deployable Artifact, and
• The need for inclusion of the concept of Internal Architecture.

Version 3 of the SAE Meta Model attempts to address these issues.

We shall shortly be launching a review process and will make an updated specification and UML Profile available to those who would like to participate in the process.
If you are interested in doing so, drop us a note on our CBDI Contact Page

To view the full report

A Unified SOA?

My Colleague David Sprott blogs this week on the Failure of SOA Standards
There is no need for me to repeat his comments.

In his blog, David comments on Navigating the SOA Standards Landscape Around Architecture, a paper recently published by OASIS and The Open Group. It seems to us and many others that this is an attempt on the part of the authors to gloss over the fact they have managed to produce three alternative SOA standards when the world really only needs one. Saying that OASIS SOA RA is ‘similar’ to the Open Group SOA Ontology is a bit like saying Cricket is similar to Baseball. Because they both involve similar concepts of bat and ball presumably this means a cricket team could play a baseball team?

It is only with a more detailed level of mapping of more precise meta models that anything useful can be done in the real world. Even then, the reality is it is difficult to mix two frameworks and meta models.

One of the intriguing things for me is the involvement of common participants in all three SOA standards efforts at OASIS, The Open Group and also at OMG. IBM in particular stands out as a vendor who appears to have put significant effort into them all, and with minimal visible consistency resulting. Why? How does it help IBM customers to provide them with a choice of three alternative SOA standards? Surely that only works to slow adoption of SOA, not to encourage it.

This was one of the major successes of Web Service Protocols – that there is only one standard for each requirement in the protocol ‘stack’. Even though the various protocols are administered by different bodies, they have managed to avoid competing. Well eventually anyway after some initial vendor-based alternatives fell by the wayside. And since then take up has been widespread. Partly this was achieved because vendors such as IBM together with Microsoft participated in only one activity per protocol and not three. Hence others were forced to make decisions to go one way or the other rather than sit on the fence and be endlessly compromised by choice.

And this is what the same groups now need to do with SOA standards. Combine their energies, put aside their differences and produce a set of unified standards – even if different elements within it are administered by different bodies, as with Web Service Protocols, so they can each retain some ownership. We only need one SOA Reference Model, one SOA meta model, one set of principles and so on. But once you have the common foundation, just like the Web services efforts, there can be parallelism. From our work on the CBDI SAE meta model we know that there are multiple views which can be modelled concurrently such as business, specification, implementation, deployment, testing etc.

That said, perhaps more of the competitive approach taken with Web Services would be apt. That is, I would rather see IBM back one SOA Meta Model standard for example, and not three. I am sure the competitive nature of early Web Service protocol standards activity really helped to force the pace – a sort of SOA ‘Space Race’. Now, rather like the pace of the space race today, I get the impression it will now be decades before we land on the SOA moon. Of course, if OASIS, The Open Group and OMG cut the stack up as I suggest and avoid overlap so much the better.

But why is this important? At runtime, clearly the vision of SOA wasn’t going to work without consensus on the interoperability standards. But I believe it would be a mistake to assume a similar consensus isn’t required at earlier stages in the life cycle. Time after time we see that the lack of a common SOA framework is hindering SOA adoption in organizations. Sure different projects can all agree to use Web Services at runtime, but the lack of any common standards before they even get to that point means that much of the SOA vision remains elusive when viewed from an enterprise perspective. It is pretty hard to have full life cycle asset management and governance over SOA deliverables if the concepts change for each phase. In most organizations, users have little choice but to pick a single vendor's proprietary solution to such requirements that complies with no relevant SOA standards.

I am reminded of object orientation pre UML. What is needed now is a Unified SOA.
SoaML, in which we have participated might be one step in that direction, at least at the modelling language level. Even so, TOGAF 9 has its own meta model, but so does Archimate, and there is one implied by the OASIS SOA RA, and so on. Then there are the differences even between The Open Group’s TOGAF 9’s coverage of SOA, and their own SOA Source Book. Do you know for example when you see a concept mentioned in one document it has the same meaning as in another? Often no definition of the concept or reference is even given so it is difficult to be sure. Clearly there is still a long way to go.

And let’s not forget that there is a large government and defence sector who are extending their own frameworks such as FEA, DODAF, and MODAF with yet more unique perspectives on SOA.

It is at least welcome though that OASIS, The Open Group and the OMG have seen the need to cooperate on Navigating the SOA Standards Landscape Around Architecture. Perhaps now they can move forward as I suggest and ensure greater collaboration and consistency between their efforts with a single purpose in mind.

We would be happy to participate in such a unified process. What we can’t afford to do unlike IBM is participate in three (even though they have all invited us to), and more to the point it would be counter productive! In the meantime we will continue to participate in SoaML and refine our own CBDI-SAE Meta model for SOA. To that end we have just published a draft V3 of our model which includes SoaML adoption.

Users shouldn't need to be shown how to navigate their way around multiple SOA standards. They just want to know "are we there yet?"

Microsoft Visio – Suitable for Modeling SOA and EA?

Over the last month, I have been looking at Microsoft Visio as a possible tool for modelling Service Architecture and other SOA deliverables and as a place to capture the Enterprise Architecture. This was prompted in part by a product report I have just completed on Orbus Software’s iServer product, which adds a multi-user repository to Visio.

Given the number of specialist modeling tools there are on the market, it is surprising how many enterprises we encounter that use Microsoft Office as their prime vehicle for capturing various items of metadata and producing the documentation and diagrams required to support their IT architecture and delivery projects. Requirements and specification deliverables are routinely documented using Microsoft Word, while metadata is captured as columns and rows in Microsoft Excel spreadsheets, and diagrams are constructed using Microsoft Visio (or even just Microsoft PowerPoint). However, there are many shortcomings to this approach in an enterprise context, and that is primarily what iServer sets out to address and I have examined in my report.

Until now, I had only been a casual Visio user. For simple diagrams we publish in reports, PowerPoint is sufficient, and also the format we provide to our customers. For more rigorous work – with our clients for example, or to produce our SAE Meta Model, then we use other UML modelling tools.

Once I started investigating though, I was impressed how simple it is to create your own stencils and templates, but moreover how straightforward it is then to connect instances of the shapes to items in a Microsoft SharePoint list. In the example below, I created a simple template for the Service Specification Architecture diagram we use in CBDI-SAE, and then linked it to a SharePoint list containing a catalog of Information System Services (TOGAF) which are classified by Service Architecture Layer.

Hence it would be straightforward to create a Service Catalog in SharePoint, and then visualise the architecture for the services in Visio. My product report looks at how to do this in iServer. Clearly that is a more robust solution than my simple SharePoint example. However, for anyone with SharePoint and Visio already at their disposal, all it takes is some effort on their part.

Hopefully I will find some time to work on a Visio Template and corresponding SharePoint Template for CBDI-SAE and make these available in the same way we have done with our UML Profile.

Let me know if that would be useful.

In the meantime, I am interested to know just how many folk are using Microsoft Office and Visio as their prime tools for capturing EA and SOA deliverables, and what your experiences are.