Service-oriented architecture offers a rational approach to building applications that meet business needs. But it isn`t easy.
Perhaps the most aggravating limitation of business software is the seeming inability of applications to accurately embody the strategy and everyday processes of the business, and to keep pace with business-process changes. To a large degree, this is because traditional, so-called “monolithic” applications are made up of individual business functions that were designed, developed and deployed to operate only in that particular application.
In a manufacturing setting, for instance, the process of monitoring a raw materials inventory might support inventory replenishment, as well as production scheduling and accounts payable. The business functions that make up this process might include identifying materials, noting when inventory is used, sending an alert when inventory dips below a certain threshold, and so on. Each group has its own reasons, and own applications, for monitoring inventory, yet the process is essentially the same. Or at least it should be.
What`s more, the developers of each of those applications may have had their own ideas about how a particular process should work, which means that a given business function would be defined inconsistently from application to application.
Worse, a change made to one application may never be reflected in other applications. The proliferation of applications as businesses grow, acquire other businesses, and add new delivery channels, products and the like, only compounds opportunities for miscommunication and inefficiency. Fold in the growing number of digital interconnections with customers, suppliers and other business partners, and it`s enough to make any CIO`s hair hurt.
Ask your line-of-business it manages: Are our enterprise architecture efforts providing business users with the business flexibility they require?
Ask your line-of-business executives: How many redundant business processes can you identify within your line of business and with other LOBs?
The goal of so-called service-oriented architecture (SOA) is to fix this growing problem. Applications built using SOA will support the same business processes that applications have always supported, but with some important distinctions.
SOA`s goal is to design and develop all the business functions that go into an application as independent ‘services`, which can then be strung together in several different ways to complete whatever business processes the business requires. And since different applications often share a single service, that service can be used and reused as often as needed.
The result: greater consistency across business processes and more agility in dealing with business change – with the added benefit of more efficient use of IT assets.
However, Hemmanth Singh, director: technology engineering at Standard Bank, believes it is necessary to separate process management concerns from both the component design and service elements of processes. He says SOA is but one of many architectural styles an organisation can adopt but warms that SOA done in isolation provides very little business benefit, if any at all. “SOA is a key style that we use to measure the packages we buy and the applications that we design.”
He has a point: redesigning an order process, for example, might require a change to a particular service, rather than an entire rewrite of one or more applications that contain the business function that service now performs. And improvements to one service, in security, reliability or performance, for instance, will accrue to every application that uses it.
However, SOA is no panacea. Overhauling the application systems of a large organisation in order to employ SOA is a complex, multiyear journey. Companies that began that journey several years ago are now testing the limits of SOA. The software a company needs to manage a growing portfolio of services, for instance, is relatively immature.
And while the technology is in place to share services over the Internet with external business partners, few organisations feel security is reliable enough to do so with anyone other than those they most trust. But the tenets of SOA contain an inherent simplicity and rational design that many, if not most, application portfolios sorely lack.
Mark Mallabone, lead IT architect at IBM South Africa`s software group, says that while the technology is fairly mature – web services standards have been finalised and ratified for a couple of years – actual implementation has lagged, particularly in this country.
“What most organisations are battling with is the fact that, to get to a SOA, you either need to go with the old-fashioned approach of putting in adapters to connect the legacy and sweat that investment; or you need to put a Web services wrapper around existing stuff. So we`re seeing a dual approach at the moment in the local market place,” he notes.
Ask your cto: What development and architectural skills do we need to support a migration to SOA?
Ask your developers: Which standards can we rely on for an enterprise architecture based on SOA?
Don`t pursue SOA before developing an IT/business master plan.
Mallabone agrees and says the most appropriate approach depends entirely on the skills an organisation has available to it, on the investment it has made and on whether or not the value can easily be unlocked from existing applications via web services. This, he adds, should be measured against performance advantages that may accrue from the use of native APIs or adapters.
Singh says overlap also exists between business processes across different LOBs on both an activity and a function level. “Businesses want the capability and flexibility to ‘build` the processes of choice, but from a set of well-defined, common services (activities and tasks).”
He says the first step in the process must be to document all processes, activities and tasks using a consistent methodology/ approach. This allows an organisation to identify the areas of overlap and provide direction to build or buy the correct components. It also facilitates process rationalisation and enables a well-defined SOA business definition to be established.
However, Singh stresses that SOA is not a golden arrow, but only part of the solution. “SOA will not `fix` processes. SOA decouples certain application layers and provides a foundation but, if it does not coincide with ‘back-end` re-engineering, the service remains a reflection of the current functions provided by the processing engines,” he explains.
According to Singh, the real value of implementing an SOA lies in the process elements that are exposed by the architecture. He also notes that there is a trade-off between flexibility and performance. Centralising applications, he adds, carries with it a need for more service level agreements and disaster recovery planning, which may well cost more.
Ask your chief architect: What is our plan for reducing maintenance costs and speeding up development times?
Tell your cfo: We can beef up our architecture budget and thus reduce development and operating costs.
Complicated as the technology is, the people problems that accompany a migration to SOA are likely to dwarf any technology concerns.
With SOA, “casting the discussion in business terms is the big opportunity, but it is also the big challenge,” says Forrester Inc analyst Randy Heffner. “Most IT people aren`t qualified to have that business conversation. You need key people to drive the business and IT connection.”
At the Hartford Financial Services Group, John Chu, senior vice president for eBusiness and technology, helped sell the various lines of business on the benefits of SOA. The Hartford began experimenting with Web services within lines of business in 1999, according to Benjamin Moreland, assistant director of foundation services, who was hired in 2003 to create the foundation – including the infrastructure and standards – for the company`s SOA effort.
By 2004, the company had defined the reference architecture – the common set of guidelines and standards that all developers must adhere to – and created an official Enterprise Architecture Group, which reports to the CTO.
The Hartford is focused on two goals: reducing maintenance and day-to-day operations costs for IT systems, and making The Hartford a company that`s easy for agents and customers to work with.
Enterprise architects now spend their time making sure newly developed Web services, which support a Web-based agent portal and the customer service centre, among other applications, meet these business requirements. An architecture steering committee that includes both IT and business people reviews projects to ensure they comply both with the enterprise architecture and business plans.
“The committee scores every project as positive, neutral or negative on whether it complies with the architecture and is going in the direction of the line of business roadmap,” says Moreland. “We don`t want IT just to be order takers. We want the business side to understand the risks [associated with their requests], especially from a maintenance perspective.”
Another concern involves the changes required by the IT staff itself. Forrester`s Heffner sees mid-level managers as the employees most likely to struggle with a move to SOA. “The notion of [sharing services using SOA] is very threatening to middle-level IT managers, who have built their careers managing a particular silo.” Part of that discomfort comes from giving up control.
“Application owners and line of business architects are used to controlling the environment, the people and the priorities,” Moreland says. “The culture was one of ‘If I don`t control it then I may not trust it.` Now these things are being shared.”
Ron Schmelzer, an analyst with ZapThink, a Waltham, Massachusetts-based IT analysis and advisory firm, predicts that in the future, many IT organisations will be organised around “service domains,” or collections of services that are logically related, rather than around vendor products (databases, SAP, CRM, and so forth), as they are today.
One domain may handle all services related to parts inventory and procurement. Another may handle all customer services. He also thinks the overall IT organisation will likely be smaller. “Companies are realising that if they can eliminate redundancies in software, they can eliminate redundancies in people.”
Albert Hofeldt, vice president of technology strategy at Thomson Financial in New York City, agrees: “Architects and A++ developers will always have opportunities, but we`ll need fewer average developers, especially developers based in the US.”
Perhaps that explains Liebow`s advice for the IT graduating class of 2005: “Don`t become developers. Become architects.”
Ask your IT managers: How much redundant effort could we eliminate with a move to SOA?
Ask your head of human resources: What training options are available to meet the changing needs of our IT organisation as we move to SOA?