Americas

  • United States

Asia

Oceania

by No Analyst or Consultant

SOA  Towards the Industrialization of Software

Feature
Aug 22, 20055 mins
CSO and CISOData and Information Security

By Judith Hurwitz

Maybe I have been around too long but I am suddenly sensing that we are entering a familiar pattern-vendors and customers focused on an emerging technology approach without being prepared for the right action for success. Everywhere there is talk about Service Oriented Architecture (SOA). No self respecting CIO leaves the SOA out of their management presentations. Likewise, no software vendor on the planet can offer a new product implementation without a salute to SOA. This has the feeling of the days of the client/server movement. The justification for Client/Server and SOA are the same: Customers want a flexible infrastructure for computing that makes the process of change easier.

I recommend a little different way to look at the movement towards Service Oriented Architecture. In essence, SOA is the natural evolution of software- it is the industrialization of software. To achieve this goal requires IT management to stop focusing only on the plumbing but to look at the components of their business in a pragmatic, nonpolitical, and systematic fashion.

This will be a hard transition for many corporations. But with any major change in approach to computing there are complexities, risks, and directions that must be addressed. I break down the key issues that determine the success or failure of the migration to SOA into three categories:

  1. Political foundation
  2. Business foundation
  3. Technical foundation

Political foundation – as usual.

Too much time is spent in organizations focused on the politics of technology acquisition. IT management often sees the purchase of a system or technology as the foundation of political power. Picking a technology platform that fails often results in the loss of prestige. Because the implementation of a SOA approach touches so many different disciplines and business units within an organization, the decision making and implementation can take on a life of its own. Organizations that are able to bring the key constituents together to draft a common view of the end goal of SOA are in a much stronger position to overcome political wrangling.

Business Foundation.

One of the biggest issues that we at Hurwitz & Associates have seen is that companies do not understand what a true SOA is and how it works. In our view, it is imperative to start from the business level and work to the physical IT environment. Too many organizations start their SOA implementation by selecting an enterprise service bus or by creating web services interfaces. While these are among the necessary steps – they should not be the first steps. The first step is to create a concrete map of the business itself.

What business are you in? What are the foundation components of that business? What parts of your business that are customer facing? Federal Express brings a package to a customer’s door. Walmart provides aggregated shelf space and marketing to product producers to satisfy the consumer. Dell manufactures and delivers packaged computer products to individuals and businesses. Each of these businesses has foundation components. These include components such as; products, customers, outlets, services, whose characteristics need to be defined and business practices; methods of processing a claim, or a product return, or an invoice, and the like. How do all these relate to each other? What are the rules that govern how business is done both internally and between partners and suppliers? How does a new product, new service, or new partner engage with various parts of the organization?

The result of this mapping activity is an improved understanding, both of the complexity of the business as it exists today and how change will impact it. This map will be the basis of planning and creating clearly defined business services that will in turn become the foundation of a SOA.

Technical Foundation.

With the business foundation in hand, the organization is in a position to plan the technology foundation for SOA. The business foundation will give the technologist a good understanding of the complexity of the business and therefore what technology components are needed both long term and short term. Like the business foundation, it is important to break the technology foundation into its component parts or services. For example, security and identity management are foundation components. So is the messaging layer, a mechanism to encapsulate a business service and create standardized interfaces to enable these parts to communicate. A common mistake that organizations make is to look at each foundation component in isolation. In fact, all of these technical components must be mapped to the business foundation. If there is no correlation between the business and technical foundation someone is planning to acquire technology in a vacuum without any business justification.

Conclusion.

Creating a Service Oriented Architecture is not a simple task. If you want success, you cannot bypass key steps and just start coding. Too often organizations just jump in without starting at the business level. Too often they get caught in the morass of political infighting for power and control, which only hampers progress towards organizational goals. I fear that if organizations do not approach the movement to SOAs from a methodical, nonpolitical and business perspective, management will become disillusioned and business opportunities will be lost. A well designed, business focused SOA strategy will enable companies to save vast amounts of money and enable them to change business models quickly. It might even provide a business advantage over competitors if a business can transform itself quickly and efficiently. But, alas, there are no silver bullets: it is hard work.