This article originally appeared in the members only BPM Strategies Magazine.  Join today to receive your own copy. 

I recently have been working on service-oriented architecture (SOA) models for various clients. Doing this, I have noticed that the models are fairly technical and mostly rudimentary. The focus of my clients' efforts are typically on the redesign of existing application interfaces to provide greater abstraction and simpler integration with other applications. However, when I query the customer about deployment and infrastructure, they acknowledge that these issues are important, but I notice that the conversation does not invoke action.

As a consultant, I care about my clients' welfare. I want them to be successful, which requires them to accept that enterprise-wide SOA is more than just a redesign of how applications communicate. I know that what I'm asking of them requires a cultural shift to occur in their organization if they are to obtain all the real benefits of a service-oriented architecture for the development and deployment of applications.

Fundamental Change

At the root of this fundamental shift is a requirement to re-think about how most IT departments operate. The IT department has typically mimicked the architectures of the day. When everything was centralized on the mainframe, IT departments were typically housed in a centralized facility with close proximity to the data center and relatively little exposure to the users. As we decentralized with personal computing, the IT department began to offer services in a more decentralized fashion, working hand-in-hand with the users.

SOA embodies a shift in both the architecture of applications and the architecture of the environment in which it is deployed. This may be one reason for the vast disagreement about the definition of SOA. Ask a developer and they will tell you it's a way to design software in a loosely-coupled manner. Ask a software architect and they will tell you that it is a way to deliver applications as a set of reusable components. Ask the operations and system administrators, and you will get a blank stare because SOA has not penetrated all areas of the organization that it needs to in order to be successful. This means that most organizations are still deploying coarse-grained Web services and not SOA.

Next Step

The next great shift in architecture is coming. It's the utility computing model and SOA is just a piece of it. In order to take advantage of all SOA has to offer, the IT departments will need to transform themselves to match this new computing architecture. I liken this change in thinking to transforming from a systems integrator to becoming the power company. As users become more technically savvy and the tools they use offer greater capabilities for collaboration, less personal contact will be required with the user once again. Instead, the IT department of the future will become responsible for creating and managing an infrastructure that is capable of continuous service regardless of the ever growing demands and larger amounts of consumers.

Your organization's introduction to SOA may be the redesign of a legacy application into a set of coarse-grained modules that are reusable, but this is simply an introduction. From here you need to leverage these first steps to look at how these new modules will be deployed, used, managed, discovered and, ultimately, decommissioned. This requires changes to your infrastructure, new tools and training, new skills and new resources. I wish you well on your path toward embracing this change and incorporating it into your organization.

JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to Morgenthal via email at morgenthaljp@avorcor.com.

JP Morgenthal's Training Course.

Bookmark / Share This

Bookmark or share this with others.