The “Practice” of IT Architecture is NOT a One Size Fits All

Chris Schultz, Senior IT Management Consultant
February 8, 2018

The legacy of IT Architecture practices in many shops is dismal at best. This is not due to any flaws of best practices, or efforts on the part of those engaged in applying Architecture methods and techniques. Generally, these practices will yield valid results that indicate how best to put all the technology enabled information management pieces in place to meet business purposes. The main flaw is the time it takes to produce “correct” artifacts. These are the models and objects in a repository that represent all the components of business processes, data, information and the information technologies themselves that support the ideal definition of the business. The Architects are often too “religious” in their methods and IT management is too quick to abdicate the “practice” objectives to the Architects. I have often seen IT management treat the Architects in much the same manner as business management often treats IT. IT wants to explain the importance of some IT item or issue, but business leaders’ eyes glaze over and they seem to just want IT to go away and make things happen. As a former IT Architect, and manager thereof, I have experienced this same phenomenon first hand from upper IT management. As an IT management consultant, in both IT strategy and Architecture, I have observed it and benefited from it. IT management must fit the Architecture practice to their needs and Architects must apply their methods appropriately to be both timely and relevant. Where to focus the work, how to execute it and how to make the results useable must all be aligned with an organizations specific goals and objectives.

The benefits of an effective and successful IT Architecture practice often fall far short due to 3 common failings:

1. A misunderstanding by IT management of what “IT architecture” is for,
2. A reliance by novice Architects on frameworks such as TOGAF, Zachman, et al as cookbooks,
3. A failure to communicate effectively, both among the IT community and with business people.

IT Architecture is not a distinct function of IT in the same way as Application Development, Infrastructure Management, Business Relationship Management, et al. Effective IT Architecture should be a disciplined approach to how IT does planning and design across all domains (Technology, Data/Information, Business Processes, & Solutions). Architecture is about ensuring that all components function together as a whole to achieve defined goals and objectives of business units. This way of viewing IT Architecture aligns with the IEEE and ANSI definition of “system architecture”:

“…the fundamental organization of a system, embodied in its components, their relationships to each other, their environment, and the principles governing its design and evolution…”

IT Management must ensure that all functions are collaborating to ensure their choices of technologies, data and business process are aligned with the same business goals and priorities. This applies at all levels (Enterprise, Portfolio, Program and Solution). It leaves open different organizational models such as having a central Architecture team(s) and a “community of practice” that lead and/or coordinate among IT functional teams for planning of technical roadmaps, or to apply standard components to a specific program or project. IT Management must also provide a clear focus for the strategic planning work of the Architecture practice to ensure they are providing a visible benefit where and when it is needed. For example, BI, the “Cloud”, Security, replacement of aging transactional applications or infrastructure. Left on their own, Architects can do a lot of good work but may not deliver timely, relevant benefits for either IT itself or to business units.

Novice Architects left on their own will often follow a framework as if it was a cookbook. The result is artifacts that conform to the standards of that framework, but may not be useful to decision makers who need them. These frameworks are most useful as a “toolkit”, not a recipe. The tools in the kit must be used appropriately to the reason they are needed. They could be used for target states and roadmaps to support business planning decisions for a Program, or first level designs for handover to those who will configure or build the ultimate deliverables. The level of precision in the content and when it is needed, will vary by the consumer and the use they will make of it. This comes back to IT management giving clear direction of what content is needed in the artifacts, and experienced Architects who know how to adapt their methods and tools for that purpose.

The artifacts, or outputs, of IT Architecture work must be appropriate for the consumer, not the Architect. The use of Architecture modelling tools is essential for the long term success of the Practice. The repository of artifacts produced by these toolkits can be arcane and not useful outside of the Architect community. The graphics and annotations that communicate clearly to business decision makers need to be different from those needed by designers and builders. Architects must ensure their work is timely, relevant and correct, but also tailor the presentation to the audience. Collaboration and adaptation among the whole IT team, Architects, managers, analysts and others is essential to address each organizations unique needs and for the benefits of a disciplined Architecture practice to be realized.