SOA is About Business

Arnon is but one of the latest attempting to define SOA in a more formal sense, stating that SOA is an Architectural style derived from four architectural styles. He presents the first here with Client/Server.

That's all well and true, but any definition of SOA must encompass the business drivers and business reasons, as SOA is not really about technology. It is about a better alignment of business and IT through business processes and services. The goal is to create a dynamic, more Agile and Dynamic IT that can respond quickly to new business opportunities and threats by quickly assembling new capabilities from putting together composite applications (and even Mash-ups) from reusable business services.

The business issues are the drivers causing SOA. We have gotten into a mess in many companies. IT departments are locked in a proprietary mess of legacy systems, averaging 80% of their budget spent on maintenance instead of developing the capability to shift IT to a strategic asset. Thus, when the business tries to act quickly, IT is not agile enough to respond. Everything takes 6 months or can't be done. Reports have to be obtained from 4 different systems, none of which talk to each other. Businesses have had wave upon wave of methodologies and efforts such as EAI, only to end up with only two tightly-locked systems now "integrated" instead of a loosely-coupled array of business assets and processes that can be reused and redeployed at will.

SOA or Service Enablement can transform a company's existing array of heterogeneous, distributed, complex and often inflexible IT systems into a set of more connected, simplified and adaptable ones that can better support the business. However, technology is not the predominant factor, neither is REST or WS-*. It has to begin with a focused understanding of what underlying business needs that have to be addressed. From there, my experience has been that a simple, pragmatic and incremental approach ("Agile") is best, gaining greater business agility by connecting disparate data and systems into new higher-order services. In this sense, SOA is not at all about "reinventing the wheel" but instead allowing businesses to gradually and incrementally leverage existing assets and "enable the changes needed for the agile business."

What does that mean? The focus for many Architects and Developers shifts from the Component Level to a more powerful Service Level. That also means that today's architects have to shift, in many cases, from a singular application focus into a multi-app focus, learning how to make applications more loosely-coupled, dynamic and exposing reusable services and processes to other applications in an SOA. IT departments can no longer afford the singular focused developer hyper-focused on his code piece and creating yet another island.