Service-Oriented Architecture

By Ed Carroll, Agilis Solutions

Service-oriented architecture (SOA) – in my view – is the latest thinking on how to best integrate multiple software applications throughout the enterprise and across business functions. In the ’80s, we did this with middleware (and no one did it well); in the ’90s, we created Object Request Brokers (because it was so hard previously, but we were constrained within the corporate network); in the ’00s, web services, XML and SOA are proving to be effective tools and opening the door to real trading partner integration.

Companies looking to grow need to have the ability to adapt to changing market conditions, while at the same time optimizing their more static business processes. When software applications do not support a business’s need to easily change as the market changes, the company risks becoming marginalized or – at the very least – the unwieldy application could slow the business down.

Service-oriented architecture (SOA) is a design approach that could help make it easier to adapt the flow of information through a company’s software applications, making it easier for a business to be responsive to the ever-changing marketplace. In this article I will highlight some of the key concepts of SOA toward developing software which integrates smoothly with other enterprise applications.

Who
When developing a business application, there are very few islands anymore. Only a few industries exist that do not have their own flavor of accounting, order processing or other enterprise software applications. And few new software companies want to replicate the complexity of the leading enterprise resource planning (ERP) applications. Therefore, if you plan to sell software to a business enterprise then your application needs to be able to integrate into the other existing applications within the enterprise’s IT environment. Often this means that a new application could potentially need to integrate into virtually every ERP application on the market (or other similarly pre-positioned enterprise applications).

Integrating into every ERP application can be quite problematic. To tightly couple a software application to every ERP application would require developing a separate set of data and integration rules that could potentially change with every new release of every ERP – a compounding problem. Even if the data and integration rules are defined within well-published application program interfaces (APIs) for each of the ERP applications, the problem is large if the integration method utilized is a tightly coupled method (data exchanged directly between one database to/from another), and often each ERP manufacturer will define a different method. SOA is a design approach that can be used to organize the hodgepodge ways that enterprise applications expose their integration points (APIs).

What
From the perspective of a software company with a new application to sell into the enterprise, the key starting point is to know what business processes will have an impact on the new software product; this can be defined in a business process model. A business process model can define the detailed processes, systems, actors and data flows that will have an impact on the software product to be sold. A simple data flow diagram (DFD) works well for this effort. I would encourage an exercise that would attempt to model, at a high level, the full business (process) environment of the target or ideal customer. This specialized type of process model is sometimes called a community of interest diagram (CID) and is useful in identifying what and where information is needed within a business environment. From the CID, business processes and actors that might need information from the new software application will emerge.

Where
Where to implement SOA depends on the target environment. Not all software products should implement an integration layer through SOA. SOA is a loosely coupled integration method, so if a tightly coupled integration is required, then SOA may not be a good solution. We’ll assume that a loosely coupled integration method is appropriate.

Working from the CID, create process models that define the boundaries, or touchpoints in the processing of data to solve (or process) business decisions. Processes to model are identified as logical groupings of business services within a workflow. The new software product becomes either a producer or a consumer application and the data in the data flows identify what data to expose in an SOA-defined API (or in SOA parlance, a service).

When
Like an ERP application that calculates the proper taxes at the proper points as an order flows through the system, there are points in time when data in any business process is changed, added or deleted. These are events that correlate to the processes carved out of the CID. Redraw these processes in an event model in order to define the triggers that force a change in state. State changes are important in the definition of what data is needed by which processes at what point in the processing (within the workflow of the processing). The event model is also very useful in identifying when a particular service can be reused – because the same data is changed, added or deleted by different processes.

How
SOA is most often implemented through web services. Think of web services as small applications that use standard transports, encodings and protocols to exchange information – enabling the integration of multiple desperate software applications. Web services are based on a core set of communication standards, including XML for representation of the data, the Simple Object Access Protocol (SOAP) to standardize the data exchange, and Web Service Description Language (WSDL) to describe the capabilities of a web service. SOA enables the integration of multiple desperate applications without having to know the internal processing of any of the applications (the web service becomes a strong, well-published API).

Conclusion
By adhering to the SOA standards, a company can easily adapt its IT environment to the changing needs of its business. Companies can create a library of business services that aggregate multiple applications and business data needs together to solve a business problem (this is called creating composite applications). From the perspective of the software product company, jumping onto the SOA bandwagon could provide the means for its software to easily and effectively integrate into its customer’s IT enterprise, no matter what other systems are already present within the environment.

About the author
Ed Carroll has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing. He can be reached at EdCarroll@AgilisSolutions.com.