You don´t need an IT Architect, you need several

Search the Internet and you will see that an increasing number of companies are looking for “Architects” to look after their IT systems. What is not clear however, are the actual expectations of this role, what kind of skills are required, and even what kind of Architectures might be possible. From a corporate perspective it is clear that IT architecture has become too complex and needs to be better planned and managed.  But how that happens and who will do it is unclear.

A little history
Let´s go back in time to the early 1990´s. Back then, IT was experiencing the beginning of the Internet era. Mainframes were still the primary enterprise platform, personal computing was growing by leaps and bounds, but many leaders were still risk-averse and reluctant to change their IT systems platforms.  As the processing capacity of Intel and SPARC-based systems grew, a downsizing trend started.   Departments started to transition from expensive mainframes and terminals and replace them with more economical mid-range servers, PC’s and Local Area Networks.

Running systems on mainframes using centralized planning and management made it relatively easy to follow set standards and enable applications availability with minimal disruption. The range of technologies and software was fairly limited and quite stable, and only a few large vendors dominated the enterprise market.

As technology improved, midrange severs became faster, more reliable and more efficient. Small businesses could take advantage of the brand new world of open architecture, and even open-source software. Most companies started having different systems architectures living together. IT infrastructure became more diverse and the computing capabilities moved out of direct IT organization control.

Distributed systems introduced even more options. Over time, companies developed systems portfolios looking somewhat like a crazy quilt, with many different overlapping components. The resulting complexity arose from having multiple business divisions each chasing their own objectives, introducing their own variety of solutions and having their own copies of data ( which may or may not be in sync with the rest of the business).

Back to the future
Technology complexity has resulted in management complexity. More people are now needed to assess and choose which combinations of technology to use. An overview of the technology landscape is needed. A multitude of Architects now collaborate to meet this need. While technical staffs are often focused on one or a group of applications, the architects need to cultivate a broader focus on the entire enterprise, navigate between multiple technical architectures, and work to design integrated solutions. The picture below helps illustrate the focus of the Architect specialties:

 

The Enterprise Architect focuses primarily on company strategy, with a broad view of IT and the business objectives.  They visualize the complexities of the business in a manner that summarizes some details and retains significant components and relationships.

The Technical Architects focus on one or more technologies and maintain an in-depth knowledge of all detailed technical aspects.  They include Infrastructure, Information and Application Architects, each one with expertise in their domain.

The Solutions Architect balances knowledge from a technical, business and information perspective, being able to navigate between all domains for a particular solution.

There are overlaps between these roles. Most of the time you won’t find separate individuals focused on each domain; some architects will play multiple roles.

Each architect role requires more than just technical knowledge. They also play a strategic role that requires building effective relationships with senior executives, managers and practitioners at all levels. As a result, Architects need to develop their “soft skills” and refine their emotional intelligence.  Architects must become masters of all forms of communication, translating between the business and technical domains. An Architect needs to explain complex ideas in simple ways tailored to their audiences, summarizing difficult concepts quickly. While not everyone is comfortable with public speaking, Architects must make an effort to develop this skill in order to operate effectively across the organization. Architects are also leaders – they must inspire others. They are also marketers, securing support for ideas and initiatives across the organization.

The adoption of Architecture frameworks is vital, regardless of a company´s size. With so many technologies living together, the need for integration and application portfolio optimization is ever-present. But don´t think of Architecture simply as technology integration. It must be aligned with business objectives – always. This alignment is what helps guarantee that future demands will be met in a timely manner with minimal roadblocks. It helps ensure that time-to-market will be optimized and total cost of ownership and maintenance costs will be in control and aligned with company revenue.

The creation of a properly staffed Architecture Office is necessary to implement the systems architecture model described above. There are four main frameworks in the field (TOGAF is one of the most popular architecture frameworks, and the one I recommend):

• The Open Group Architecture Framework (TOGAF)
• Zachman Framework for Enterprise Architectures,
• Federal Enterprise Architecture (FEA), and
• Gartner Enterprise Architecture Process and Framework (formerly Meta Framework).

The vision is simple: businesses are always evaluating the “as-is” and planning the “to-be” (or target outcome). Companies must always stay in motion, as all markets are dynamic -- change is the only constant. Hire an Architecture team that can design a safe path to get you where you need to be.