In-Depth

SOA: It’s the Business that Matters

Those who have built and deployed successful SOA projects know it’s all about meeting business needs.

One of the best parts of my job is I get to travel a great deal to meet with countless people to discuss their technology initiatives. Over the past couple of years in particular, I have traveled around the world several times and met with architects, project leaders, and CIOs who are at varying stages of adopting service oriented architecture (SOA). The key lesson I’ve learned from those who have built and deployed successful SOA projects is that it’s all about meeting the needs of the business.

I have found that IT architects intuitively understand the value of building an SOA, but most have trouble explaining it to others in the company. Getting buy-in from the rest of the business is a critical factor in getting your SOA initiative off the ground. The key to success getting buy-in is to align the software projects with the business problems that need to be solved.

From my work with CIOs, it’s clear that there are always plenty of primary business imperatives that are top of mind for the CEO. They usually involve improving operational efficiency or increasing top-line revenue by attracting and retaining customers. Attracting customers may mean creating new products and services and new marketing programs to reach them. Retaining customers can include quickly reacting to products, services, and programs constantly introduced by your competitors. It may also mean improving customer service. These are all things that require software systems to help implement and automate. Find those initiatives and you will ensure that your SOA projects get the attention they deserve.

A great example of finding the top business imperatives comes from a Progress Software customer. Its gas exploration and distribution business has grown over the past 10 years to a billion dollar company through aggressive merger and acquisition. A critical need for this company is the ability to rapidly integrate acquisitions and make them more efficient. After these years of M&A, they were doing financial rollups using Microsoft Excel. They took stock and found that they had 150,000 spreadsheets, many of which were being used as part of a manually integrated solution.

Working with the executive team, IT leaders identified 40 high-value projects which they realized could potentially benefit from being implemented as a SOA. They prioritized the top five projects with the most immediate business impact. The first of these consolidated accounting to take on the spreadsheet problem.

They found a champion in the business to help get the SOA projects funded. Nobody gets funding from the CFO and CEO simply by describing a new architecture that’s really cool and is going to solve all their problems. Decision-makers have heard that before with EAI. Most CEOs and CFOs don’t want to hear about architecture, loose-coupling, buses or any such techie talk. They are results-oriented and don’t usually care how the IT department implements it. They will remind IT that they can’t seem to keep up with the change requests as it is. Find someone on the business side of the house who is responsible for one of the top business imperatives, convince that person that your SOA project can help them, and let them help champion your cause with the holder of the purse strings.

Only the Beginning

Once you find the top business imperatives, your job is only beginning. You must create a vision of the big-picture solution and be prepared to articulate it regularly and consistently. This helps build the longer-term plan and gain support from other teams, other departments, and from upper management. I regularly hear from senior-level IT architects that they spend the majority of their time evangelizing and reinforcing their vision to their own people at all levels about what they are trying to accomplish. This is an ongoing process that continues even after the SOA projects are under way.

Meeting the Needs through Flexible Business Processes

SOA is an architectural pattern of loosely-coupled, reusable components that form composite applications that can be changed as needed. The goal of an SOA project should be to create flexible business processes through loosely coupled services that can be put together to form composite applications that automate specific business functions. This is where the real benefit of SOA can be realized. As business requirements change and functionality needs are introduced, the business processes based on SOA must be capable of adapting to change more readily than those that are written as stovepipe applications or those that were hard-wired together through some other means.

Architects and developers should not be concerned with building plumbing and connectivity infrastructure. Architects and developers should be focused on building composite applications that leverage existing services and making sure that everything is aligned to support business objectives. This is where using a flexible infrastructure such as an enterprise service bus (ESB) allows you to visually model business processes as interactions between services and to configure the dependencies between services rather than hardwiring them into code at each service directly.

Governance and Compliance

Adopting SOA requires new governance models and compliance measures to ensure that the new architecture is helping the organization and not putting it at risk. With stringent government regulations such as Sarbanes-Oxley, organizations need to be acutely aware of, and be held accountable for, their bookkeeping practices. In the software sense, this means monitoring, auditing, and reporting your daily business transactions. The introduction of SOA can make this easier since it may provide visibility into services that can be audited and logged.

However, a SOA may magnify the complexity of this issue. For example, what if a service that was written to perform a not-so-critical business task suddenly starts getting reused by a different business process that requires strict auditing, logging, and encryption? How are you going to identify and distinguish between services that require strict attention to governance rules versus those that don’t? This is where a SOA management and governance platform can help by putting the enforcement of business policy into the infrastructure rather than hardcoding policy enforcement and governance into each individual service. It may also be capable of tracking and enforcing behavior of a service interaction based on the context of which business process the service is being used.

Summary

You are putting an architecture in place that will be pervasive across your enterprise and is going to prevail for many years to come. Make sure you do the proper planning to align SOA with the needs of your business. Build flexible business processes that can accommodate future changes and ensure that the proper governance measures and business policy enforcement are in place for rapid adoption of SOA.

Must Read Articles