On Demand: Agility Required

My wife sat next to my 9 year old daughter sharing a moment of watching a video on Youtube. My daughter watched, came to a part that she didn't enjoy as much and slid the play-slider up to another part. My wife responded by saying "that's really annoying, you learned that from your older sister."

I paused her and explained that for my daughter, media is an on-demand experience. Pick what you want, watch it, skip parts you don't want, rewatch parts you particularly enjoy, and share it with friends & family with a click. Whereas my and my wife's experience is broadcast media. You watch (or listen) to what comes on, watch it from beginning to end, and if you missed it - oh well. We don't interact with or adjust our watching experience - she does.

(I've actually been in the car with the radio on and had my children say "could you pause it and put that back, I didn't catch what he said".)

Clearly for those in the media business this poses a major paradigm shift in the expectations of their consumer. This changes not only how they package and deliver their product, but how the meet the challenges of a new customer interaction pattern. They need a level of agility that was never previously even a minor business concern.

Unfortunately, like my wife and I, most of the media executives come from a generation that had a different interaction pattern. This makes it difficult for them to intuitively grasp the changing expectations of their customer base.

I find a similar scenario in many corporate IT shops. The customer expectations have changed or are changing quickly. For example, which is more important in your banking relationship today - the convenience of the branch location and customer service level in the branch, or the capability and functionality of the customer account web site? (Personally, I once dropped consideration of a new bank because they didn't integrated into a Quicken automatic import, and changed to another bank that had a significantly more advanced account management web site and online bill pay options.)

Now the business comes to the IT department with what is essentially a new requirement: rearrange the systems to expose data and transaction functionality directly to the customer. And further, be prepared to adjust and manipulate as customer expectations continue to change. In other words, agility.

SOA came along to help solve this problem. However, the problem is legacy applications. NO ONE (that I know of) has a SOA - a Service Oriented ARCHITECTURE. They have a mass of legacy applications running their business that suddenly need to be twisted to move from primarily operating via their user interface to operating via a service interface.

I met with an insurance company recently, one that literally did not exist 10 years ago and was created as a direct-to-the-customer company. Their "legacy" applications are only 10 years old, yet they are just as much bound by their legacy environment and the paradigm upon which it was built as the Fortune 50 corporation in New York that has 40 years of computer infrastructure behind them. Both are struggling with offering new customer facing functionality.

One must architect for agility. Every IT shop has an architecture, whether explicit (designed, maintained and molded towards current and future business needs) or implicit (as business requirements were placed upon each individual project, an overall enterprise architecture developed out of the combined project results from those requirements). As the need for agility has grown, it must be expressed as an explicit requirement, both upon individual projects and across the IT enterprise.

SOA will help with that requirement, but is not the end all of agility.

Dodging the Cutbacks

Dr. Jimmy Schwarzkopf (IT analyst) wrote...

Today I visited a client whose IT budget is no more than 1.6% of its revenues. His boss asked him to cut 20% of the capital investment and 10% of the operational budget (a total of 10% compared to budget 2008). In order to do this the company will stop projects that could have increased revenues, some that could reduce costs and some cuts would increase the risk of IT failures. Now my thoughts: By cutting 0.16% of revenues (as expenses) the company lost much more. Does it make sense to cut IT without a real analysis???

Clearly this company has designated IT as a pure expense center and utility service provider. As far as the business management is concerned, IT is no different than:

Facilities Management - Tell them to cut and they can eliminate the office plants and cut back on window cleaning.

Cleaning Service - Tell them to cut back and have a somewhat less clean office.

Security Service - Lock a few more doors inconveniencing how people enter the building but doing with less security.

Travel Expenses - Tell employees to travel less, stay in cheaper hotels, eat cheaper meals.

In this mindset, from IT... the network won't be any faster next year, the business doesn't really care. Desktop computers may be changed less often, again the business doesn't really care.

This client's IT department has failed to explain or demonstrate that they offer a business advantage, rather than just being a necessary burden for operation. IT management practices have allowed the business to categorize them as expendable. At this organization, interaction with the IT department is a major hassle. You describe what you want, you get something else. You pay IT budgets but see no measurable (from your business department perspective) value.

This IT department is divorced from the business drivers.

The result in the U.S. of such a positioning in the past resulted in complete outsourcing of the IT department at some companies (to EDS or IBM GS or Perot Systems, etc.) In the current downturn, we see some major companies having overall corporate layoffs at one level, say 10%, but IT layoffs at a higher level, say 25% (example of this: Metlife). In this model, improvement of business efficiency or opening of new sales or product channels via IT is not seen as a key factor to business survival.

Alternatively, IT is seen as fat and inefficient. Lack of flexibility of old designs, complete lack of systems architecture (as opposed to haphazard system building), and mis-alignment with business goals has resulted in many an IT organization that indeed is expensive and rather unresponsive to business needs.

However, as Dr. Schwarzkopf noted, a lack of analysis of how or why one's IT department is like this and just going for the big cut (instead of targeted surgery) will hurt many a business's future. (Of course, if a business is struggling to survive the year, such concerns are irrelevant.)

If you want to dodge the cutbacks of the future, make sure you the IT person understand what the business concerns and drivers are, and can demonstrate how you are helping to achieve them. Then DO demonstrate it, both in actions (deliver for your business) and in presentations (make sure they know it!)

A brief expense story: While working for a US Fortune 50, to save money the company decided to relocate several thousand employees out of New York City due to the office expense. The employees were scattered out to different offices depending on where the majority of the department lived - some going north to upstate New York offices, some going west to New Jersey offices, and some going east out of Manhatten to cheaper parts of the city.

The following year the company saw travel expenses explode as employees travelled around between 6 offices to meet and do their jobs. So they announced travel restrictions. The following year the company saw conference calling expenses explode as employees compenstated for the travel restrictions by engaging in long multi-office conference calls to do their job (which went even higher as due to the length of such calls, people wouldn't get together in a conference room but all call in from their desks to multi-task). So they announced an effort to cut down on... Finally they analyzed what groups needed to work together, reduced the number of offices people were spread about, returning to the original efficiency and reducing the travel and conference expenses - 5 years later.

Clouds and SaaS

While IT analysts and pundits are busy declaring SOA is dead, SOA has failed, and the downturn killed SOA, the hype of 2009 is Cloud Computing and the resurgence of Software as a Service (SaaS). (Microsoft Azure being a prime example.)

In my discussions with my corporate clients, as well as from my own extensive corporate history, I'm finding that allowing key corporate data and processes to leave the walls of the company controlled data center is the main mental barrier to SaaS and Cloud Computing. Even though companies are outsourcing business processes and the associated data that goes with them - as well as outsourcing some applications to hosting providers - the thought of deploying their applications to an amorphous cloud and depending upon the vendor to just "support and provision it appropriately" is a mental leap they're not yet prepared to make. Similarly, relying upon services that a vendor will just "support and provision appropriately" is a similar leap of faith they are not yet ready for.

While corporate management has become more and more comfortable with Business Process Outsourcing - and telling the IT guys to "just interface with them" - most IT management has not yet made a similar jump. This may be due to IT management struggling with a definition of what they provide, what is their core competency. Few companies outsource their core competency, doing so would invalidate their existence. Most IT management still defines data center operations and computing resource provisioning as part of their core competency, rather than a focus on maximizing the automation of core corporate business processes.

Being that IT environment stability is a key IT operating factor, this is understandable. The question will be whether SaaS and Cloud providers will be able to create environments of matching reliability (to traditional corporate data centers) and provide sufficient business guarantees to make savings, flexibility, and dynamic provisioning worth the risk. (What risk? The career risk to IT senior management in case of failure, or simply the risk of the unknown.)

As always, some bleeding edge companies and managers will give it a go. If it goes well, they will gain a strategic advantage. Leading edge companies will gingerly dip their toes into the water, trying a few projects and evaluating the possibilities for future potential. Mainstream companies will sit on the sidelines and wait for the early adopters to shake out the bugs, especially in 2009's tough budget environment.

Related Link: Integration is a Thorny Issue for SaaS at Mergers and Integrations by Loraine Lawson.

SOA is Dead says the Analyst

The article of the year is from Ann Thomas Manes at The Burton Group: SOA is Dead, Long Live Services. Nothing like a provacative title to get your attention.

SOA from a vendor perspective is whatever tool they are selling in the space: ESB, Design Time Governance, Runtime Governance, Policy Management, Registry & Repository, etc. What they always sell is the tool, never the process.

Since the A in SOA is Architecture, and the true value of SOA is SOA for the Enterprise (as opposed to SOA for Integration), it takes implementation of a SOA architecture pattern to get the hyped SOA benefits. But as noted above, this is not what vendors are selling.

As most organizations focus on SOA for Integration and layer on a few tools rather than applying architecture and an organizational change process (which, face it, is hard), only incremental benefits will be gained. This is not a surprise, IT managers are rarely rewarded for shaking things up and taking risks.

Much of SOA is about creating, managing, motivating organization changes - the process of which is not unique to SOA but SOA for the Enterprise is completely dependent upon.