Blog

The Art of Establishing an IT Architecture Program – Part I

Posted at July 8, 2018 | By : | Categories : Blog | 0 Comment

The Art of Establishing an IT Architecture Program – Part I

Gary Silberg, Senior Solution & Enterprise Architect

July 8, 2018

 

So you want to establish an Information Technology Architecture Program in your organization? You think your IT projects haven’t been fully successful under the leadership of your Project Managers, Business Analysts, and Technical Leads? Can an IT architecture program really make a difference? Let’s explore this problem together. There’s actually an art to establishing an IT Architecture program.

 

Why create an IT architecture program?

You’ve probably been reading a lot lately about “Enterprise Digital Transformation”. Articles appear in many business magazines and social media websites about “Digital Disruption”. Every research and advisory firm is talking about “Digital Business Transformation”. Entire conferences focus on exploring the future of the “Digital Enterprise”. Gurus and pundits are talking about the “Fourth Industrial Revolution”. Industries are undergoing dramatic changes, from taxis (Uber) to retail (Amazon) to Pizza (Domino’s).

There are innumerable guides and approaches to help organizations along the journey to a digitally-transformed future. Many stress the importance of an effective partnership between business and IT. Some mention that the enterprise architecture team can be helpful, but point out that a large proportion of business leaders don’t know what this team does. Even fewer mention the role of solution architecture in the transformation. Despite this, an IT architecture program can be a strong enabler for your organization to implement your digital transformation strategy.

 

When is the right time?

If you recognize any of these business and IT problems in your organization, the right time to set up an IT architecture program to help you overcome them is now. 

Within the business units

Reports arrive at executive meetings from different departments with “differing versions of truth” about business results. Senior management asks questions that existing business applications can’t answer. Impacts of business decisions can’t be effectively measured at a useful level of detail. New business initiatives can’t be introduced because it will take too long for the application portfolio to support them.

On projects involving automation

Key design decisions are hard to make when trade-offs between additional solution features and extra time and cost are needed. Projects are delivered on time and on budget, but learning and using the new system is difficult. Response time is slow and users get incomprehensible error messages. Data converted from old systems is wrong or missing in the new system. Frequent long outages are needed for “system maintenance”. After an unplanned outage, system restart takes too long and lost data can’t be restored.

With existing business applications

Applications run in their own “silos” with little ability to interact with other applications. Some application areas have two or more different solutions that have significant functional and data overlap. Senior management has difficulty combining information from business units to get a clear picture of overall company performance. Employees need to learn to use many different applications to do their jobs and require lengthy training. Required regulatory changes are hard to complete within the timeframe allowed.

 

 

Who should be on your team?

Part of the art of creating an IT architecture program is to acquire a good mix of competencies and experience within the group. But there is no specific course to teach someone how to be an IT architect. Effective architects are developed from work experience and mentorship, not from training. You need to live through projects riddled with problems and delays along the way. One of the best ways to learn the importance of architecture is to stay on the application maintenance team for a number of months after the new production system is deployed. You get an appreciation for the kinds of issues that arise when architecture considerations are missed or downplayed. These anecdotes come in handy later when you are trying to promote the value of your IT architecture program.

Certification vs. Experience

Some people think that they are an architect once they have an architecture “certification”. This is like saying you’ve received a diploma in carpentry, so now you can build a skyscraper. Certifications in a number of architecture frameworks are available. These run from “Zachman” to The Open Group Architecture Framework (TOGAF) to methodologies from consulting firms and software tool vendors. If you have taken training in any of these frameworks, you have a basic understanding of what architecture documents look like and the process of creating them. But there is a big difference between creating architecture models and supporting the delivery of automated solutions that deliver business benefits.

The most influential IT architecture programs are made up of experienced individuals from a variety of backgrounds. Some team members are internal candidates who have been coached on projects by other architects, while others are hired externally. Ideally, your program will have a diverse group of both. This heterogeneous mix of people will allow potentially contentious architectural ideas to be vetted within the team of “friendly” architecture colleagues before the ideas are presented to others in the organization.

Soft skills are critical

Technical areas can be researched to get up to speed, but interaction with stakeholders to convince them to change is much harder. Never underestimate the damage that can be done to an architecture program by even one architect with weak interpersonal skills. On one project, I was given the title of “Integration Manager”. When I asked why I wasn’t simply called the “Solution Architect”, the answer was that the previous architects had been so exasperating that the title of “Architect” was no longer allowed to be used!

The architecture program needs people with foresight who are conceptual and innovative thinkers, but who can also use logical analysis and their experience to make good decisions and solve difficult problems. They must provide effective workshop facilitation and excel at influencing others using non-authoritative leadership to build consensus. They must also be able to tailor an approach for each project to match its scope and size and then be able to create the corresponding project deliverable list and work estimates. They have to be oriented towards continual learning to see how new technologies can be used to create business transformation. They need to be influential coaches—for other architects within the program and for members of the supported project teams (some of whom may aspire to become future architects).

Choose a strong leader

The most important individual in your architecture program is definitely the leader—sometimes called the “chief” or “lead” architect. It isn’t sufficient that this individual be experienced in both enterprise and solution architecture. Outstanding leadership skills are also required. This individual should be someone well-respected in the organization, business-oriented, and strategically-minded. Enthusiastic and passionate, the leader above all must be exceptional at presenting innovative business processes and solutions in ways that inspire senior stakeholders to take action.

 

Where in the organization should your program report?

There are a number of different organizational models that can be used to implement an IT architecture program. One recurring challenge is that architecture assignments aren’t always full-time and often have gaps between work tasks, especially within smaller projects. The more centralized the reporting structure, the easier it is to manage the peaks and valleys of demand for architecture skills. The following illustrates a few design scenarios with pros and cons for each:

Program reports to one IT Architecture Lead, who reports to the CIO

This structure allows for excellent alignment with IT Strategy and how it supports the business. It promotes strong communication between architects for effective solutions and problem-solving. It is easier to manage the program by allowing each architect to be allocated part-time across multiple initiatives. However, Project Managers and Application Sustainment leads may not be assigned the specific architect they request. Sometimes conflicting project schedules require supplemental temporary resources to meet peak demand. This seems to be the most common structure.

Program reports to several managers within IT, by business unit

This structure provides good alignment with business unit strategy and its supporting technology. Architects retain more in-depth knowledge and relationships with their business unit. However, architects are connected more informally with each other, making it more difficult to foster clear architecture communication. Since the workload doesn’t neatly divide into full positions across business units, it takes more effort to manage the peaks and valleys of demand. The distributed organization makes architecture careers harder to manage, which leads to retention issues.

Program reports to several managers within IT, by technology area

This structure aligns the architects with the trends in specific technology areas, and may uncover new technologies to support business unit transformation. However, the architects are further removed from business and IT strategies, and this increases the tendency to focus on technology rather than the business value of solutions. The issues of communication, demand management, and career development are also dilemmas in this design scenario.

Program reports to one business lead outside of IT, for example the CFO or CEO

This structure has the potential for the strongest alignment with enterprise business strategy. Architects have the opportunity to truly transform the business using disruptive technologies. However, unless the business is directly technology-related, it is rare for the IT architecture program to report outside of the IT department. The most common set-up includes a few IT-oriented staff being involved with the strategic planning groups.

Special situation – IT consulting firms

Within consulting organizations, the IT architecture program is frequently called an “Architecture Practice”. There are often a number of additional roles performed by these consultants:

•  Provide support for the sales team to communicate offerings

•  Author client proposals, including solution definition, delivery approach, work effort and cost estimation, and risk profile determination

•  Provide technical review of proposals and quality assurance of delivery work

•  Monitor new technologies and trends to contribute to the development of new consulting offerings

•  Mentor consultants to develop future architects

•  Support recruiting by conducting technical interviews to establish candidate competencies

There are advantages to keeping the architecture practice together organizationally. Having one architecture practice fosters more interaction between architects and promotes an architecture consulting career path. By working with a variety of salespeople who have different styles, the architects develop better skills for sales support. In contrast, distributing architects organizationally within consulting firms often leads to burnout and loss of these key employees due to the tension between the business drive to increase sales and the persistent focus on 100% billable hours. The architects provide the most value when consolidated into a larger team reporting higher up in a consulting organization where the leadership can effectively balance their utilization between sales and delivery.

In Part II of this blog, we’ll consider the kinds of output your IT architecture program should create, and how to make the program in your organization successful.

 

Mr. Gary Silberg is a Senior Solution & Enterprise Architect affiliated with IT Architects in Calgary, Alberta. Gary most recently led an architecture practice for an international consulting firm, and has provided architecture consulting services in various sectors including government, oil & gas, utilities, transportation, healthcare, financial services, manufacturing, and retail. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, and the deployment of leading-edge technologies. If you require further information, Gary can be reached at info@itarchitects.ca or 403-616-3210.

 

Leave a Comment