So, where are the architects?

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 rats' 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 that we need someone in the corresponding role for designing systems as complex as today's IT environments.

The Enterprise Architect's Roles and Responsibilities
We last discussed the importance of the enterprise architect to any SOA initiative two years ago. Since then, many companies have launched their SOA initiatives, and as a result their enterprise architects are now fully engaged in planning and guiding their architectural rollouts. As a result, the specific skills that this elusive service-oriented architect requires are crystallizing. Specifically, companies need enterprise architects who can merge the worlds of business and IT in order to make service orientation a reality. Such an architect should be able to perform the following functions in the organization:

• The Great Communicator: Since part of the definition of architecture includes the environment of IT, namely the business and its extended enterprise, a key duty of the architect is the ability to keep one leg firmly planted in the business and its requirements so that IT can always be responsive to the business and not vice-versa. An architect can translate ill-defined, abstract or incomplete business requirements into a set of service definitions or a model for how to define those services in spite of ongoing, unpredictable change. In effect, the architect serves to intermediate the worlds of IT and business in much the same way that the human resources department isolates the business users from having to know all the intricacies and complexities of hiring and firing employees. In much the same way that we seek to simplify the IT world by abstracting its complexity, the architect helps to create an abstraction of the IT organization to the business user and provides a corresponding abstraction of the business to the IT organization. Having a good architect in place will prevent the rest of IT from speaking directly to the business organization, which is in fact a good thing.
• The Simplifier: Businesses are complex entities. IT is likewise a complex assortment of disparate technologies. There's simply no way that any one individual in the company can have an adequate understanding of all the intricacies of both the business and IT worlds. Thus, the enterprise architect has a key role in distilling the complexity of the business world into a set of more easily understood service definitions, processes and associated metadata. Likewise, the architect needs to simplify the complicated morass of IT technologies and infrastructure into a set of reusable services and contracts that define the obligation of IT to meet ongoing, changing business requirements.
• The Evolutionist: A good architect realizes 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. Architects need to be able to implement technologies and approaches that help them encapsulate changing requirements into metadata as well as maintain the evolving set of services in the company. The business organization is clearly not responsible for maintaining these services as they change over time, but neither is the IT organization responsible for maintaining changing business requirements. You can think of business and IT users simply as the parties that engage in a contractual relationship with the architect as the role that helps define the terms of the contract and make sure that both parties abide by the terms they've agreed to.
• Champion of Thrift: There's sufficient technology in the organization to meet much of businesses' ongoing requirements. However, most companies simply don't have enough understanding of architecture to make efficient use of existing investments. We can't count on business users to think strategically about IT agility, since if it were up to them they'd simply continue their practice of making decisions based on the most expedient, cost-effective solution to their problems of the day. Likewise, we can't depend on the IT rank and file to focus on thrift, since most developers and operational folks within IT would much rather implement the latest technologies and cutting-edge infrastructure than work with the hulking system that's been chugging along for the past decade. 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.
• The Pragmatist: 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. Since business users and individuals within IT each see the elephant that is IT through their own perspectives, the architect must be able to see the elephant for what it is, maintaining a pragmatic mental picture for how the organization can evolve iteratively while still maintaining a single, cohesive vision of the organization's architecture.
• Master of Best Practices: Rather than focusing simply on using the latest, greatest technologies or delving into the latest acronym or business fad, the architect is responsible for developing the best practices for architecture for the organization. Good architects will have the opportunity to not only define a business' overall approach to architecture for the years, and perhaps decades, to come, but might even have an impact on the IT industry as a whole. Whereas the IT developer and implementer was the innovator of yesterday, the architect is the innovator of the future.

ZapThink Take
It is certainly possible for those that have traditionally been in the IT role to become architects, but they must be able to think in terms of architecture and be able to fulfill the functions we described above in a credible way. Likewise, it is also possible for someone who has spent their entire career in the world of business to be able to gain enough IT knowledge to become a credible architect. So, what is required here is for the new breed of architect to develop in such a way that they are capable of thinking in terms of in the agile, flexible, service-oriented way that the business requires.

Thus, we leave with you the admonition that it's not good enough to simply call yourself an architect and do one or two of the above tasks. A successful SOA demands that you develop your communication, simplification, economic, leadership and best practices skills. If you can pull all these disparate capabilities together, you will be seen not only as the individual who can make SOA happen, but finally give companies the architecture they've needed since the dawn of IT.