5 days ago I created a LinkedIn group for the CBDI Forum. Within days we had a few hundred members registered and some really interesting relationships building and discussions. Last night I decided to open the group up to our wider membership - it evidently worked, and seeing other groups with thousands of members I had no qualms that the "system" was anything other than to be trusted.  

This morning as members were responding to my overnight email newswire the joining and management functions stopped working. The site became intermittently available. This was very frustrating as I had invited my customer base to register, and it was simply wasting peoples' time.

I sent a note to LinkedIn Customer Service. Then I looked around on the Web, and wished I had done so earlier. Here's a selection:

Every year CBDI attempts to make an assessment of where we are at, and the key drivers for our next years R & D program. Last year (2008) we identified “make it real” as a theme, and in many respects we have delivered on this. Clearly the major achievement this year has been the huge advance in the CBDI Knowledgebase. With Release 2.0 now launched we now have a body of guidance that is now getting used in earnest by early adopters and ready for widespread usage. In addition the tooling and profile work we did earlier in the year, plus detailed modeling and a strong emphasis on practices. More recently we have been focused on addressing “real world” topics which has spawned M&A, Multi-channel, etc.

Looking forward to 2009 the macroeconomic situation is of great concern, but my reading is that SOA is moving out of the hype phase which has been characterized by tactical application to becoming business as usual (BAU). Larger enterprises, governments and consultancies are now acting to put in place high quality, repeatable practices. So while the credit crunch will have a temporary effect by reducing overall demand, there is evident and increasing demand for methods and guidance in the area of quality, repeatability and productivity.  

For CBDI research I see five primary areas of demand for our R & D:

1. Productivity, cost reduction, business value.  – Survival in recessionary times. Focus on key cost and headcount reduction strategies including Testing, Offshore and Outsourcing, Managed Services. Estimation. M&A.
2. SOA as Business as Usual. We have already started articulating this message, but in 2009 we need to make a major transition where we go beyond SOA to BAU. For example:
   - develop resources such as templates to the next level of detail (XML schema).
   - work with industry providers to create tool specific reference implementations
   - refine service specification and other deliverables by life cycle stage
   - export task lists to Project Management tools
   - reference architectures for technology platforms (e.g SCA)
3. Standardization. CBDI has blazed a trail where others are following. Our meta model and profile, SOA process and life cycle have been widely adopted, cloned and copied. We have donated our core concepts and models to various groups including the OMG, HL7 and TM Forum. We have also participated in the OMG’s UPMS. In 2009 we will look to influence more rigorous concept models and align our work with emerging standards.  We will look to integrate or align with de facto Project Management approaches, ITIL, and other frameworks (possibly TOGAF as it matures).
4. Better Business Model. CBDI believe that de facto business modeling and requirements approaches are woefully inadequate for purpose. Lots of the individual components (techniques, languages etc) are fine for a narrow purpose, but they are all predicated on yesterday’s world in which we abstracted away from the real business problem in order to make realization with the limitations imposed by technology. Today many of these technology limitations are removed, yet we still draw line and box diagrams, and never give a thought about a richer conceptual model that underpins a loose coupled world that is in constant evolution.
5. Evolving SOA Architecture for Cloud, SaaS, IaaS and Virtualization. SOA architecture is an integral component of the emerging technology environment. There is a need to move our reference framework forward to provide initially, the conceptual Framework for SOA in these emerging domains.

All feedback and comments welcome.

I continue to observe examples where SOA is deployed primarily as a technology strategy which worries me a lot. Yes SOA technologies will provide loose coupling but they won’t address abstraction, reuse, standardization etc. in my experience the areas of maximum business value.

One application area that is very commonly linked to SOA is multi channel. SOA seems a natural fit – enabling common services for concurrent use in multiple technology channels such as ATM, branch and kiosk, or Web, call center and mobile. Of course channels are very often technology enabled opportunities and the justification for the investment in the new channel is precisely because of the technology viability.

But the technology layer is essentially about providing a delivery mechanism or interface to the “consumer”. In addition there will be business model components that further define the channel that need similar consideration so that a) new or altered channel capability can be introduced as rapidly and cheaply as possible and b) business processes are designed such that cross channel interaction makes the channel as effective as possible for the “consumers” and “providers”.

In developing a general framework for multi-channel, we identified a number of these business model components have the same architectural consequences as technology. In addition to the delivery or interface these include Product Class/Consumer, Commercial Channel, Pricing Type and Product Delivery Technology. We don’t pretend this list is exhaustive, rather a starter for your thought processes.

The same thinking can also apply to merger and acquisition, which when you think about it often introduces new channels, either temporarily or permanently. For example Royal Bank of Scotland (RBS), running the two retail banking brands RBS and NatWest as two "channels" with consolidated support systems and cross channel selling.

As an organization extends into more ambitious multi-channel arrangements, the potential value it can get from SOA is increased and it occurs to us that sophisticated multi-channel architecture and business models are indications of very mature SOA capability. Talking of which I note this month reports from the 5th Telco 2.0 Executive Brainstorm where the Telco 2.0 model[i] was under the spotlight. This emerging concept is a shift in business model referred to as a 'two-sided' telecoms market structure; where telcos facilitate improved interactions and transactions between people and organizations. While telcos must continue to attract retail consumers they will extend the capabilities of traditional consumer products to support enterprise business processes by creating open and standardized platforms that third party organizations can plug their enterprise IT and communications systems into - just as they plug into the telephone and Internet networks today. Sounds like a multi-channel world.

For all these reasons we have decided to specialize this month’s CBDI Journal on the multi-channel topic. In addition to a significant report on a framework for multi-channel business and communications, we look in some depth at how Dell has utilized SOA multi-channel for business value.

When I researched and wrote my report for the September Journal on M&A I commented that the level of mergers this year was way down on the last 2 years. Well! How wrong can you be? In the space of one week everything has changed. Bank of America and Merryl Lynch, Lloyds and HBOS, Barclays and Lehmans, and not forgetting the US Government becoming the effective owner of AIG, Fannie and Freddie. And that's not mentioning airlines!

What's really interesting is that these mergers and acquisitions are all protective measures to avoid a financial market meltdown. Yet, in my report I said "Today M&A is probably the most disruptive, high risk event that a business willingly undertakes."  So for all these businesses and the others that are almost certainly in train, the big issue is how to make them work?

The problem is most M&As, however professionally selected, choreographed and managed, are normally executed using something close to crisis management. In my report I suggest that M&As really need a mature SOA environment - which of course facilitates a high level of controlled change. And I go on to say that while most organizations are a long way off having that SOA maturity - actually there's lower risk in aggressively adopting SOA that using the usual blunt instrument M&A approach used by the consulting industry - which BTW almost always fails to deliver the promised business value in the planned timeframe. 

See my editorial M&A or Business as Usual? and my research report SOA & M&A. In the research report I provide a structured approach to planning and executing M&A that is based on SOA principles.  

I recently spent a week in the city of Buffalo, in upper New York State. I hadn't been there before. It's a relatively small city by US standards, but what struck me immediately was the building architecture. Everywhere you go there are quite amazing buildings. The most striking are the Art Deco skyscrapers. But tucked away there are several examples of the designes by Frank Lloyd Wright - recognized as the greatest American architect of all time.

Wright is regarded as the originator of the "open plan" style. Of course if you are sitting in the ubiquituous cubicle reading this, you may not regard that as a giant step for mankind. However whatever you think of the instance, Wright demonstrates consistency of "style". You can see the open plan in houses in Buffalo as easily as you can in the Guggenheim museum in New York that he designed decades later.

And it's the question of style that we can learn from. Style is this somewhat woolly hard to pin down thing. But it will be enduring and consistent. It's supported by concepts. And the concepts are supported by patterns and best practices. As I see it, today we are all furiously agreeing that the style (SOA) is not in question. Likewise the concept (service). But the industry as a whole is incredibly immature in terms of patterns and practices.

I listened to Denis Hageman from ABN AMRO speaking at a conference in London recently. His subject was managing outsourcing. And he described how a very large organization evolved from a chaotic to controlled state in its management of third parties. However he admitted that they still struggle to govern the architectural details. It's not an easy thing to do. Achieving the balance of cost and SLA delivery against architectural compliance is like walking a tight rope. (my analogy). My sense is that we have a huge amount to learn, and this is just one area where we can use the SOA style and concept to develop much cleaner contracts.

Recently we published a report on SOA contracts. It didn't go nearly far enough, but what it did is mark out the landscape. We need to evolve from plain ol' WSDL to behavioral contracts, to SLAs to build contracts that govern what gets delivered. We have a way to go. 

Read more on Denis Hageman's views on outsourcing in my conference notes; and more on architectural styles and patterns in my June CBDI Journal editorial.

In June I attended and spoke at the European Enterprise Architects Conference in London. Some 250 architects fromm all over Europe.  The theme of the conference was very much about business alignment - moving the EA function into a much more strongly business function. But it was interesting that when one speaker asked the main tent "how many of you are IT people?" the vast majority were in that camp!

In my main tent session I asked the question "how many of you are now engaged on deploying SOA in a strategic manner?" One person put a hand up. And that's where we seem to be. SOA is widely adopted at a project level, but as yet there is no real engagement of the business. 

Read my conference report 

My colleague Richard Veryard commented the other day “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 . . “

Here at CBDI the primary principle underlying our work is to go beyond the trivial, to provide practical guidance to what are complex issues and questions. So I am really pleased to see a book on SOA that is demonstrably practical. SOA Demystified, by Juneja, Dournaee, Natoli, and Birkel (Intel Press 2007) is a report from Intel architects on their experiences in applying SOA. Keys to the success of the book are a) equal emphasis on organization and technology and b) case studies of how SOA has been applied at Intel.

The fact that Intel is using the CBDI methodology is a mere bonus!

I have had discussions around this question numerous times over the past few weeks, including with some Gartner folk who of course sparked a lot of the interest with their predictions report. (“beginning in 2007 BPM will become the driver for SOA implementations. Convergence of BPM and SOA may not fully mature until 2010”). This prediction raises many questions, but let’s just address why ever should BPM and SOA converge? Because this may also solve the question of what, how and when!

After I spoke to the Dutch SAP User Group last week one of the delegates made some interesting comments about the Maturity Model that I had presented. The first point he made was that the Maturity Levels were not part of a common set. His comment was that Early Learning, Applied and Integrated represent states whereas Enterprise and Ecosystem are scopes. I responded that actually apart from Early Learning, all the levels relate to the scope of the SOA. However I accepted that it might not be entirely obvious!

The second question related to the scope of the SOA maturity model. My questioner’s assertion was that the scope of SOA was synonymous with BPM. I disagree with this latter point rather profoundly. BPM is an important driver and consumer of SOA capability, but it’s only one of many, which include business capability development, application rationalization programs, data rationalization and more.

But to return to the maturity level comment this did get me thinking. If I wanted to rationalize the maturity levels to be more consistent with a scope perspective I could do as follows:

An article from John Crupi (reference below) reminds me of many discussions around the topic of “what do we do with services?” For many, services are simply a mechanism to expose back end functionality that can be consumed by a composite application. But I have always been more than a little uncomfortable with composite applications because they are a kluge – to the extent that many refer to mash-ups and composite applications in the same breath.

I note in the UK yesterday a row over government plans to create a huge database integrating personal details across government departments. The BBC reports “A centrally held, single source database of people's personal details could be created at Whitehall under government plans so people do not have to repeat personal information to different public bodies - particularly at times of stress such as a family death. Tony Blair is expected to unveil the proposal in Downing Street on Monday.”

Frankly this is incredible. Where are the government architects? Have they ignored service architecture concepts and the opportunity to avoid precisely this sort of outdated disaster inn the making. But this raises a much more serious question – what are we as architects doing to educate politicians, citizens and business people to understand the difference between modern service oriented architectures and conventional database driven approaches?

A new book by David Edgerton challenges some of our most deeply held assumptions. He suggests we confuse innovation with use and that resulting misconceptions lead us to unthinkingly accept clichés such as “change is constant”, or “we are subject to ever accelerating change”.

Beware salesmen bearing inappropriate children’s gifts at this festive time of year!
I note resurgent interest in Lego^TM blocks as a metaphor for explaining to the business audience the value of SOA. My advice is don’t treat the business audience as dummies! Business people need grown up explanations, not over simplified ideas that give dangerously false impressions of ease of implementation. In this blog I suggest that there is a really good way to explain the business value of SOA and that's using a model that business people fully understand already - The SERVICE CONTRACT MODEL.

A CBDI member commented on Richard Veryard’s recent report “Data Management for SOA” in the November 2006 CBDI Journal that the lack of semantics “is a significant weakness of the UDDI concept since it would be very dangerous to consume services dynamically without having a thorough understanding of the underlying semantic model. The results may be valid but meaningless”

I observe there is increasing appreciation of the importance of semantics for SOA - driven by need for provider and consumer to have shared understanding - and this is reflected by a number of standardization initiatives.

In a provocative post yesterday, David Linthicum suggested that Enterprise Architects should be fired if they don't appreciate SOA. Not surprisingly, this is resulting in a hostile response from people (Uche Ogbuji, Mark Nottingham) who are saying that it's not Enterprise Architecture that's the problem, it's SOA. Or rather the SOA vendors. Mark (who used to work for BEA) blames the Big Vendors.

I have some major concerns with the way SOA (or some watered-down version of SOA) is being implemented in large organizations, sometimes with the encouragement of vendors. But I don't think all the blame for this can be placed on the vendors. (Hey, they're vendors, what do you expect from them?)

I also have some major concerns with the way Enterprise Architecture is being implemented in some large organizations - talking endlessly about Business-IT Alignment but reduced to playing meaningless games of Framework Bingo.

In our consulting work, we are increasingly finding that effective SOA and effective Enterprise Architecture go hand-in-hand - you probably can't do a decent roadmap or business case for one without considering the other.

I think David Linthicum raises some good points in his post, but I don't agree with his conclusion that you should fire enterprise architects who don't appreciate SOA. It is probably true that some enterprise architects don't deserve that job title - but it's not because they don't appreciate SOA but because they actually aren't very good enterprise architects in the first place.

I have generally found that good enterprise architects are eager to address the issues that matter to their organizations. This certainly doesn't entail (why should it?) an uncritical acceptance of SOA. In my earlier post on Optimism (in reply to Jeff Schneider) I said that "it is not the role of the architect to be optimistic". But it does entail striving for a flexible and joined-up and cost-effective architecture. Frankly I can't see the point of an enterprise architecture if it doesn't do any of the things on David's checklist.

Technorati Tags: EA Enterprise Architecture SOA service-oriented

As you might imagine I don’t spend a lot of time listening to what Gartner Group says. In fact CBDI membership registrations strongly suggest the opposite is true! However one of our members gave us feedback that at the recent Gartner conference in Cannes there was almost no coverage on SOA!

It’s not hard to figure out what’s happening. Gartner has a market maturity model that predicts every major IT trend will go through what they refer to as the “trough of disillusionment”. Gartner’s own Hype Cycle shows the Technology Trigger being followed by Peak of Inflated Expectations before Disillusionment, which may be the precursor to the Slope of Enlightenment. We might imagine they are preparing their case!

What’s really interesting here is that the Hype Cycle is specifically defined as the graphic representation of the maturity and adoption of specific technologies. Yet hopefully most people know by now that SOA is not a technology. SOA is an architectural style that is merely enabled by technology.

Norwich Union has been running a pilot Pay-As-You-Drive (PAYD) car insurance scheme for a little while, and has now made this policy generally available for UK drivers. There are differential rates for insurance depending not only on the number of miles driven but also on the identity of the driver (under 23s pay more than older drivers) and the context (daytime versus nighttime, motorway versus town).

PAYD is also being proposed as a solution to road congestion.

We have discussed PAYD as an interesting example of differentiated service, and we are looking forward to seeing how popular this kind of service is among consumers.

CBDI Journal: Service-Based Business: Insurance (October 2003)

Norwich Union website, TrafficMaster website, BBC News report

Wikipedia: PAYD
Technorati Tags: insurance PAYD SOA service-oriented