Thinking Architecturally Blog
This is the first of a series of articles regarding IT architecture for the strategic design and implementation of solutions that benefit the institution. Hopefully there will be a bit of humour, whimsy, or tongue-in-cheek, but most of all these articles aim to be useful or thought-provoking to a few readers.
By Frank Boshoff, January 25, 2017
Most people are familiar with the traditional roles of building architects, but the term has been borrowed by the IT industry (since about 1993) for roles that, at first glance, don’t seem to have anything to do with large structural entities that occupy physical space. IT architecture might still be a bit of a mystery to some people. According to the International Standards Organization (ISO) “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
An IT architect colleague in the U.K., when asked what he did for a living, often replied “I get paid in electrons to move electrons around to make people’s lives easier.” (the “paid in electrons” bit was because in all his professional career, he had never been paid in cash and relied on computer displays to determine his cash position. There are many parallels between what IT architects and building architects do – it boils down to strategy, design, modelling…the forward thinking required to avoid “early termination”.
Early termination (i.e. an early and somewhat unexpected death) is why architecture became a necessity in the first place. We are thin-skinned animals and we need shelter from the elements and predators. We figured out how to build shelters with the resources at hand and discovered that shelters are more valuable if they provide better defense capabilities (the three little pigs…castles…nuclear intercontinental ballistic missile silos…this theme doesn’t look promising does it…). If the shelters enabled additional capabilities (e.g. workshops to increase GDP), all the better. Building architects can take a client’s idea and turn it into a reality. IT architects do much the same, but in a different medium.
—— As computing systems became more complex, avoiding early termination of large (i.e. costly) IT projects became more important, and senior management wanted someone accountable for the forward thinking required to avoid disaster (and to blame if disaster struck). Most solutions in the early days of computing consisted of a single machine, but things work better when they’re designed to work together so computers were enabled to communicate with one another (thanks to some brilliant systems engineering).
—— Everything seems to be more complicated now and IT solutions typically consist of multitudes of computers run by numerous different entities and paid for by various different stakeholders. Computer systems started to multiply like rabbits in the 1980’s. By the early 1990’s efforts were well underway to try to make sense of the complexity (e.g. Computer Aided Systems Engineering) and the IT Architect term was beginning to be used by the large IT consulting firms (likely helped by the higher billing achievable because of the fancy sounding title). It could be argued that these efforts contributed to even more complexity. Nowadays, some IT professionals aspire to be called an architect because it seems one does less work and gets paid more (that’s a fallacy, of course…no, really).
There are different types of IT Architect disciplines (networking, security, infrastructure, software…) but there are roughly two categories:
- Enterprise Architecture
- Solution Architecture
Solution Architects are synonymous with building architects. Building architects are responsible for designing buildings or complexes that meets client requirements. When tasked with designing a structure for, say, a heavy-duty truck depot, they ensure that the doors are large enough and the floor will be reinforced appropriately for the load. There is enough space and capacity to maneuver the trucks and park them. There is enough light and ventilation in workshop areas. They will also take into consideration any particular requirements a client may want, and provide various options or alternatives from which the client can choose. They are also responsible for ensuring that the building fits into the environment and complies with government regulations.
Solution Architects are responsible for the technical integrity of an IT solution. When designing a solution to address a set of requirements, they strive to balance the cost of the implementation against the desired objectives. The job requires knowledge of existing computing systems and the consideration of new technologies that may decrease implementation costs without increasing risk.
Enterprise Architects can be thought of as city planners. City planners determine what types of infrastructure/demographics are best suited for particular areas of the city – they take a broader view of a city’s requirements than would a typical architect. City planners, for example, will lay out a strategy for the city to be able to accommodate truck depots without negatively impacting, say, family-oriented suburbs. Wider roads and easy access to freeways contribute positively to health, safety, and human stress levels.
Enterprise Architects take a much broader view of solutions, including people, process and technology while Solution Architects purposely focus more on the technical aspects of a specific solution to ensure appropriate IT support of academic and administrative objectives. A sprinkling of technology can definitely help speed processes, enable traceability, and make people’s lives a bit simpler (if technology isn’t making your life simpler, it’s probably not the right technology, or perhaps there isn’t enough technology). Enterprise Architects help link processes and technologies so that things work better together.
All IT architects are responsible for design integrity, and diligence is required at all levels of a project. Processes and frameworks have been developed over the years to enable consistent levels of quality in the design and implementation of solutions. Some of the best of these tools have been customized for the University’s context and are applied by Solution Architects at the University with the objectives of lowering project risk, containing implementation costs, and delivering the capabilities expected. Enterprise Architects use methods and frameworks (e.g. Cynefin – David Snowden; Enterprise Canvas – Tom Graves) to help make sense of complexity, and thereby embrace it.
At U of T, some of the larger software development teams (e.g., EASI and IITS in Arts and Science) are starting to apply Solution Architecture guidelines. The objective is to improve the quality of the solutions and boost the flow of information across silos, while also lowering the risks regarding privacy and security.
If you’re considering any large (costly) and/or complex/critical IT initiative that requires data from any of the central ITS systems (e.g. ROSI), consider engaging an IT architect for a quick consultation to determine if some additional forward thinking would be beneficial . My contact details are below.