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.

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

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.

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.

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.  

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 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!

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?

Continue reading "BIG BROTHER DATABASE DINOSAUR"