Service Oriented Department

There is much talk these days regarding Service Oriented Architecture (SOA) and the focus is primary geared toward software. In an SOA, modular distributed software provides services which can be aggregated and negotiated on the fly to solve complex problems. But are IT departments ready for an SOA software architecture if they are bogged down with the maintenance of infrastructure, instead of developing maintainable services.

Perhaps I am a bit off with this, but it appears to me that the proliferation of the Personal Computer has much to do with the transition from Information Services to Information Technology. So much time is spent simply providing and maintaining technology devices and the infrastructure that supports them that there is little time left for anything else.

Without architecture, there is little left between strategy and implementation. Some would say projects are between strategy and implementation. But as someone pointed out to me recently, strict project management is about doing the things the right way, not necessarily doing the right things. How do you know what to do and when to do it? And how do you make sure you have enough resources available to do more than catch up with support response?

Architecture is not infrastructure. Infrastructure relates to the maintenance of technology components to provide utility. Architecture is the the mapping of infrastructure to services to business needs; it is the definition of the information supply chain. Where has MIS gone? Who needs what information when? And how do they get it?

In the early days, Data Processing departments housed the data repositories, information was requested centrally, and experts made computers transform data into information; or in some cases only generated enough data for management to turn into useful information. Today, Information Technology departments largely supply the vehicles for users to produce and consume their own data. Somewhere between the two value-add has been lost.

What is the product that modern IT organizations deliver? Should there not be product lines, or services, which are evaluated in a similar portfolio as in a manufacturing or service company? How are those products and services evaluated for success?

Is not the success of a service partially defined as one that meets real customer needs, authenticated by increased use over time, sustained by reduced marginal cost of continued delivery or expansion.

What defines a failing product or service? One which is used by fewer individuals and costs more to maintain each year. Without removing failing products, eventually 100% of IT budgets will go toward maintenance.

So many solutions delivered by IT organizations meet a single need well, and yet shorten the horizon of future opportunities. The primary goal of architecture is to reduce complexity and thereby eliminate the inhibitors to change. Can we draw some lines that allow us to understand how today's decisions affect tomorrows opportunities?