If you've been paying attention, one of the things that the movement to the sort of agile IT that service-oriented architecture (SOA) enables is a new set of roles and responsibilities in the organization. We often blame today's IT departments and their technology purchases for being responsible for the integration rat nests that are the cause of today's inflexibility, and we frequently chastise the business folks for making expedient, short-sighted decisions that only make the problem worse. So, is there a way out of this puzzle? Is there anyone in the organization that can hope to get the vision of service orientation right or is this all a hopeless struggle?
Fortunately, there is hope and it comes in the form of enterprise architecture. As we've frequently discussed, the most critical part of making SOA work is doing architecture well. So, if there's a need for architecture, then it figures that there's a need for architects. After all, if we need an architect for something as relatively simple as a house or office building, then it makes sense we need someone in the corresponding role for designing systems as complex as today's IT environments.
Now, this is where things get a bit dicey. Just like every other term we use is hopelessly overloaded with multiple meanings that are often contradictory, so too does the term architect invoke continuous teeth-gnashing. Just like every other term we use is hopelessly overloaded with multiple meanings that are often contradictory, the term "architect" invokes continuous teeth-gnashing. Are we talking about network architecture, information architecture, systems architecture, business architecture, enterprise architecture, some sum of all the above, or some new thing that addresses a new need?
This is what causes the blood pressure to rise in those in the community that already perceive themselves as architects of one fashion or another. If you've been around long enough in IT, you've probably built your own base of knowledge, best practices, methodologies and technology concepts that you can wrap into a bow and call architecture. And if it's good enough for you, then darned it, it's good enough for everyone. Right? WRONG.
What businesses want are individuals connected inherently with the business of the organization and not today's technologies that approximate (at best) how the company operates. These sorts of individuals we have been referring to as enterprise architects, but perhaps there is a better term for these folks. For now, let's just assume that the above term defines a specific set of capabilities in individuals.
So, what do we expect from these individuals? First, these individuals aren't just developers with enough experience to say what works and what doesn't. They have a specific set of talents that simply cannot be organically grown from an arbitrary individual in the IT organization. Specifically, this breed of enterprise architect, the kind that can make the business stand up and recognize how to best go about something, rather than just a part of the IT department, is a rarity in the organization.
Good enterprise architects have six core talents that they master in order to give the business organization the strategic capabilities of leveraging IT in the face of continuous change. They must be great communicators – no ifs ands or buts about this one, no communication means no ability to connect the parts of the organization together. Good architects realize that nothing ever stays the same. As such, architects are responsible for not just meeting today's requirements using today's technologies, but managing change as well. It thus falls upon the shoulders of the enterprise architect be the champion of thrift and extend the value of existing IT investments. Such architects must be able to find ways to reduce the need to invest in unnecessary technology and allow companies to build systems that can evolve with changing needs. Good architects must be more than great communicators, simplifiers and economic magicians—they must also be able to make realistic, step-wise improvements to the business use of IT. Finally, good architects must understand best practices, since they are the masters that make it happen.
Yet, while there's a glut of developers who can piece things together if you can give them the proper context, there's a dramatic shortage of skilled enterprise architects with the above talents to make SOA, or any long-term initiative, work in the face of continuous change. In part, there's not enough knowledge or skills in the industry to mature wanna-be architects into full blown architect professionals. ZapThink, along with other groups, are seeking to improve this lot by introducing SOA-specific and EA-specific credentialing and skills uplifting such as the Licensed ZapThink Architect program and Open Groups's AOGEA efforts.
But more than that, there are indeed a growing base of enterprise architects with the above credentials who are not only available, but willing to help companies make the transition from need-it-yesterday and need-it-cheap IT project-by-project decision making to architectural strategic planning that considers IT as a set of agile resources to be utilized by the business. Through ZapThink's Architect Resource Center as well as other efforts, we are trying to help raise the visibility of these architects with specific skills in human interaction. Already, dozens of such architects are now in the database, with more added daily.
It may sound like a daunting task to bring together all the necessary people required to make SOA a success, but even the largest companies probably have no more than a few dozen enterprise architects with the necessary scope of responsibility to be important additions to your SOA efforts. Your key is to find these cherished and skilled individuals so you too can be on the road to effective enterprise SOA.
About the author
Ronald Schmelzer is a senior analyst at ZapThink LLC, an IT advisory and analysis firm specializing in the architectural and organizational changes brought about by the movement to XML, Web services and service orientation.
