elemental links

SOA Archives: The Evolution of SOA, from Integration to Business Scenario Development

For this post, I’m reaching deep into my archives.  In January 2005, I wrote a freelance piece published by the Patricia Seybold Group entitled The Evolution of SOA, from Integration to Business Scenario Development. 

Recently, it occurred to me that with rampant SOA hype, artificial boundaries and premature obituaries behind us, we are now on track for what I described almost 5 years ago.  Services and service-oriented techniques are the base for a new era of ‘mix and match’ business solution delivery.  More specifically, the term I floated was “business scenario development”. 

The report introduction:

“Service Oriented Evolution

Topping the list of must-have technology strategies in 2005-2006 is service-oriented architecture (SOA). Services and SOA are an important IT architectural strategy that will change how software is developed, used, and sold.

However, SOA is not new; leading companies have been employing services architectures for years to provide consistent multichannel experiences to their customers, to integrate with partners, and to reap IT efficiencies through reuse.

What is new is what you can do with SOA. We believe the current uses of SOA (integration, adding application functionality, building new service-oriented applications) are merely the first stages of the service-oriented evolution. In the longer term, SOA will be the springboard that propels IT organizations away from traditional application development toward delivering IT instantiations of business scenarios, or business scenario development.

In business scenario development, IT business solutions will be compositions of services, business events, and business processes matching the interactions of your business—with customers, partners, employees, and regulatory agencies—in the support of commerce, collaboration, and information exchange.

While the idea of business scenario development is intriguing, in order to get there, you need to start at the beginning. You need to establish solid service-oriented practices, a deep service catalog, and an extensible SOA environment.”

In the report, I share my SOA definitions, an early release of my service classification scheme, some truths about services and SOA, and some service catalog starter tips.  However, the report’s central focus is the SOA evolution business scenarios. 

Rather than excerpting the 15-page report, I’m once again focusing on the scenarios, via the report illustrations.  If you’d like to read the corresponding descriptions, the report PDF is here.

Keep in mind the illustration titles –- Now, Next, Future – reflect January 2005.

Using Services to Integrate (click on picture to enlarge)

Using Services to Add Functionality or Build New Applications (click on picture to enlarge)

Combining Services and Events (click on picture to enlarge)

[For more information on the Service and Event tie, see my Event Driven Architecture Overview]

Combining Services and Business Processes (click on picture to enlarge)

Combining Services, Events & Business Processes (click on picture to enlarge)

As the report wraps up, I offer two insights as relevant today as when I first published them in January 2005:

“As demonstrated by our examples, as your service catalog grows, so do the possibilities for your business.”

“It is easy to imagine how many of your business scenarios can be achieved by mixing and matching services, events, and business processes. It all starts with SOA—and so should you.”

Even though my term “business scenario development” never reached meme status, the underlying ideas are now at the forefront of IT delivery.  Our focus is no longer domain scoped and bounded applications, but rather solutions that match business intent and support business interactions.  The base for resolving these business scenarios is, and will continue to be, services and services architecture.

What are your ‘Rings of Defense’?

I’d like to attribute this recent ‘catching up on my reading’ to long sunny summer days in my Adirondack chair, but no such luck.  On the few rainless days, Zephyr has commandeered my chair.  Despite these obstacles, I’ve still managed to find time to read, and share some interesting articles.  Today, an article in June’s Fast Company caught my attention.  The article is entitled “Through the Fire” and shares strategies Cisco, Corning, IBM, Intel and Schwab are using to survive in the current economic crisis, and emerge even stronger as the economy rebounds.

Of the profiled companies and strategies, Corning's Rings of Defense clicked with me.  I can see the connection to business architecture, the business of IT, and business IT alignment.  [As readers know, I prefer “business-IT integration”, but I’ll go with the crowd this once.]

Corning’s Rings of Defense (emphasis is mine)

“If anyone should be able to build a shatterproof fortress, it's Corning. But during the telecom crash earlier this decade, the specialty glassmaker for everything from medical devices to consumer electronics to cars saw revenue nosedive from $7 billion to $3 billion in 18 months; Corning almost burned the village trying to save it. "We vowed never to let that happen again," says president and COO Peter Volanakis. Corning's executive team, the same senior managers as during its epic fall, instituted an early-detection system to identify signs of trouble as well as four "operational rings of defense" to help it manage through a crisis in a measured, strategic way.

The first step? A good offense. Corning created its own market-research system, relying not just on its customers but also on its customers' customers, even checking stores to measure demand for the products it helps to create, such as LCD TVs. Corning also stockpiled cash, which enabled it to absorb a $400 million loss in the fourth quarter of 2008 without selling off part of its business, as it had to in 2002 to make a debt payment. And it helped that the company modeled worst-case scenarios and a response to each.

As trouble started brewing last year, Corning implemented its first ring of defense: discretionary spending cuts, reduced production, and hiring limits. As things got rapidly worse through the fall, management quickly implemented the second and third rings: shorter work weeks in Europe and Asia, limiting its use of contractors and temps, and, finally, layoffs. But as hard as it was to trim the staff by 13%, that was a far cry from the telecom crash, when it shed 21,000 of its 43,000 workers. This crisis feels more under control, the actions "more thoughtful," Volanakis says.

Most important, Corning has avoided the last ring, which would include reducing its $630 million annual R&D spending. Its lifeblood is new products, such as those it's aggressively pushing this year -- scratch-free touch-screen glass for cell phones and laptops, smaller next-generation data centers, and a laser-light engine that turns a laptop into a projector. "We're an R&D-based company," Volanakis says. "R&D is the absolute last thing we'd cut."”

So, what stood out to me?  First, the use of scenario planning.  A long standing practice to envision the future and craft responses, which unfortunately many companies neglect to do when things are going well.  Clouded by ‘bubble fever’, perhaps.  From a recent WSJ Article:

“Use of scenario planning rose following the 2001 attacks, to about 70% of executives surveyed by consultants Bain & Co. in 2002, up from 30% in 1999. Since then, Bain's surveys have found fewer executives using the tool, though the consulting firm expects heightened interest this year, because of the recession.

"It's sort of like flood insurance," says Michael Raynor, a corporate-strategy expert at Deloitte Consulting LLP. "Everybody runs out and buys flood insurance the year after the flood."”

The second thing, was the “rings of defense” concept.  The diligent and deliberate articulation of responses, in this case cuts, that provide short-term relief, while protecting the future, in Corning’s case, R&D.  Too often, in bad times, unilateral cuts are made, disregarding long-term implications.

So, my questions for you to consider:

1. Does your organization do scenario planning?  Is this purely a business activity?  Or does IT participate?  Is the practice extended to the business of IT?

2. Has your organization articulated rings of defense?  Is there general knowledge of what business activity should be in the center, protected by the last ring?

3. Has your IT organization articulated its rings of defense?  Do the IT rings, the activities and capabilities being protected, align with the business rings?  Or, do the IT rings subvert the business rings?

McKinsey Quarterly- CTO to CEO: Why we need an annual report for technology

The McKinsey Quarterly just published a good article on how to communicate the business value of IT to the business community.  The article is a “memo” from the CTO to the CEO articulating the “lack of shared understanding” between business and IT, and then proposes a solution, a co-authored annual report for technology:

“The idea is quite simple: you and I would jointly issue an annual report for technology—something analogous to the annual report for investors and the broader market. This document would not only provide a candid overview of our ability to extract business value from technology but also substantiate that analysis with hard metrics. We would share perspectives on the challenges of technology, convey our ideas about its role in our company, celebrate achievements, and articulate our plans and visions for the future.

To show that we are serious about bridging the gap between technology and the business units and to discourage people from seeing the report as an attempt by IT to plead its own case, it’s important that you and I issue the report jointly.”

The report contains several sections, including an executive letter explaining the premise of the report, with summaries of the technology portfolio’s performance, contribution, financial value and future plans.

The article continues with examples of report sections, exhibits and metrics.  Respecting the premium nature of the article, I’m not clipping the text or exhibits, but the key points I gleaned are:

1. make the connections between business areas and technology visible

2. demonstrate how IT contributes to operational and strategic results (not just goals, but results!)

3. identify and quantify IT & technology portfolio capabilities

4. communicate the above in business terms, using clear graphics, metrics and real-world anecdotes.

If you struggle in communicating the value of IT to the business, I recommend reading the article. [Subscription required.]

And yes, I’m fine with paying for good content, namely The Economist, HBR, MIT Sloan, WSJ and (obviously) The McKinsey Quarterly.  Recession or not, budget line items for “brain food” are essential.

Federal CIO appointment, enterprise architecture and innovating / improving via technology

By now, you've probably heard that Vivek Kundra has been appointed Federal Chief Information Officer (CIO) at the White House.  I don't know Mr. Kundra, but I've seen nothing but positive reaction from those who do.

What I find interesting is the responsibility of enterprise architecture as described in the press release:

"The Federal Chief Information Officer directs the policy and strategic planning of federal information technology investments and is responsible for oversight of federal technology spending.  The Federal CIO establishes and oversees enterprise architecture to ensure system interoperability and information sharing and ensure information security and privacy across the federal government. The CIO will also work closely with the Chief Technology Officer to advance the President’s technology agenda."

The next paragraph continues with the CIO's business mission:

"President Obama said, "Vivek Kundra will bring a depth of experience in the technology arena and a commitment to lowering the cost of government operations to this position.  I have directed him to work to ensure that we are using the spirit of American innovation and the power of technology to improve performance and lower the cost of government operations. As Chief Information Officer, he will play a key role in making sure our government is running in the most secure, open, and efficient way possible.""

Now, my question is, doesn't (shouldn't) enterprise architecture also contribute to "American innovation" and using "the power of technology to improve performance and lower the cost of government operations."?

Is this delineation of enterprise architecture and chief technology office restricted to US government IT?  Or, is it starting to crop up in corporate IT as well?

What do you think? Is this delineation a good thing?  Or, do you find it troublesome? 

Resolving centralization / decentralization tension with SOA?

Robert Swanwick pinged me about a post he wrote contemplating an organization's struggle to balance the tension of business unit independence and IT consolidation.  At the end of the post, Robert wonders aloud if SOA is an answer:

"However, the autonomous business units lived on. Because they are quite independent, they are constantly seeking to diverge in order to meet the specific needs of their customers. At the same time IT continues to work towards increased centralization. As you can imagine, this is creating some tension.

A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation. If IT can control the main architecture and help facilitate the sharing of approved web services, this firm may be able to get the centralization they need while allowing for business units to meet their own customer needs.

Is SOA the way that this increasing tension might be relieved in many organizations? I doubt IT is going to give up working towards standardization and cost savings and I know that if business units feel their customers are not being served by what IT is providing, they are going to continue pushing for autonomy. If not SOA, how is this tension going to be resolved?"

Before I give my two-cents, let me issue the standard consultant disclaimer that in the absence of deep context on the particular situation, the best I can offer is educated conjecture.  In other words, "it depends".

On the IT side, a SOA approach can be used to rationalize application and information portfolios, therefore "centralizing" the software assets that instantiate common business activities and business information actions.  As well, these now common services (business and information) can be composed into interactions specific to each business unit by applying different processes, steps, rules, policies, interfaces, events etc.  So, from a purely technical point of view, yes, it is possible to balance commonalities (centralization) and variations (decentralization) with a SOA approach.

That said, the ability to achieve this outcome hinges on the given organization's maturity.  And to be clear, I'm referring to the entire organization, not just IT.  Some top-of-mind starter questions to asses organizational maturity:

• Do the various business unit owners recognize they have commonalities with the other business units?
• Is sharing (economy of scale) part of the culture?
• Are the business unit owners willing to collaborate, and able to agree, on standard definitions for those shared activities and information?
• Will the (economy of scale) benefits achieved be reflected in the business unit owner's performance?  Is there something in it for him/her?
• Is the organization experienced in IT Governance, particularly around the funding and prioritization of shared services?

If you answered "yes" to the majority of the above, then yes, consider a SOA approach to balance the tension of business unit independence and IT consolidation.  If you answered "no" to the majority of the above, understand that a SOA approach while not impossible, will be much much harder.  Read: increased time, money and organizational angst.