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:

I’m frustrated

I’m extremely disappointed!

Luke said: I have a very serious group on Linkedin which has been gaining momentum and rolling along wonderfully. The whole process of managing it has now been thrown into chaos since Friday the 15th Aug. I no longer have the e-mails addresses of the members to help steer the groups direction. All my pre-approved members have gone! Some of the members I approved last week are not in the group and are now lost ! I cant sort my members into date joined order which I find really useful for some situations. Something has to be done about this ! I had so much faith in Linkedin but its amazing how fast this ddisappeared.

 

I’m confused

Someone anonymous said: LinkedIn just changed (translation: "broke") many things about LinkedIn Groups. Nice "upgrade"

Arrggh.

 

I’m sad

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Response from LinkedIn Customer Service 12/11/2008 04:34 PM

Dear David, Thank you for contacting LinkedIn Customer Support. Recently, this portion our site may have been temporarily unavailable, an issue which was not specific to any particular group. We apologize for the inconvenience this has caused you. Our site should currently be up and fully functional.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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 

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:

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.

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.

Wherever you are in the world it is unlikely you will have missed the reporting of last week’s events at UK airports, in particular London’s Heathrow. In a nutshell the UK Government announced, in response to highly creditable police work in detaining alleged terrorists, the very highest level of airport security. The result was nothing short of chaos.

I note Grady Booch, interviewed recently has made some interesting comments on SOA including: "It is simply a mechanism for reaching into systems. You see organizations rushing to [implement] services, but they are really missing the fundamental engineering principles. In about 18 months, they will complain SOA doesn’t work. They’ll be blaming the wrong thing. They should be blaming their architectures and best practices."

I note Microsoft has completed the acquisition of Softricity, a provider of application virtualization and dynamic streaming technologies. Softricity provides Microsoft with an application and OS management process that will create a foundation for software services infrastructure. Using Softricity's application virtualization technology  we can expect applications will be served centrally and delivered directly to the user's desktop in an isolated, virtualized image, minimizing application-related alterations to the operating system and compatibility challenges with other applications.

Combined with Softricity's software streaming functionality, virtualized applications will be dynamically sent over the network, effectively whenever and wherever a user needs them. The approach creates the option of a centrally managed software service in which applications are available when and where needed and are easily updated.

Every so often an enterprising industry analyst manages to create a huge debate by challenging some of the pillars of the industry. The debate de jour was sparked off by the Burton Group suggesting the Java Platform, Enterprise Edition (Java EE) is not going to survive as a major standard programming model in the next five years. Like one of those prehistoric animals that went extinct because it got too big to live off the available foliage, the Burton analyst said that with the release this spring of JEE5, the Java EE platform has grown too complex to be workable for enterprise developers, who are increasingly looking at alternatives such as Ruby-on-Rails.

It seems that there is in general a strong trend to the casual, informal and unstructured, epitomized by the contrast between Microsoft and Google. However the danger is that we assume all classes of problem can be solved in the same way. Real world enterprise class problems usually contain a mix of high and low structure, and require an architectural framework and policy structure that reflects this. 

I have been quite concerned recently that many commentators and advisors who should know better have been characterizing SOA as instant gratification. In the last few weeks I attended a major conference in Washington DC where supposedly influential people were advising – “don’t worry about delivering the right services - because they are inherently flexible they can be changed, orchestrated or replaced so easily”. Another speaker suggested that “the answer to today’s explosion in services was to use semantic ontologies to discover and patch together services that were never intended to cooperate”. 

I also attended a presentation last week that was titled Agile Architecture. The presentation turned out to be a somewhat evangelical presentation on agile methods. But agile architecture it was not. To be fair the presentation did mention “project” architecture, but then rather depreciated the thought by saying that on an agile project everyone is an architect. Really?

When asked about enterprise architecture the presenters just brushed the question off as not really relevant which upset a good few people in the audience – it was a conference about architecture for architects.