Just before the Christmas break I wrote an article that explained why I think we are entering a new phase for technology where everyone needs to be able to understand something of the architecture of technology within the businesses they operate to make decisions that will sustain in the long run. Having had a couple of weeks to reflect, I reckon it might be helpful if I actually now gave some pointers as to what “lay architecture” might actually look like – and why that is important. That’s what I’ll do in this and the next few articles…
To start with, it’s worth explaining what the world of tech actually means when it talks about architecture. It’s a spotlight under which I found myself some years ago when I was working with some folk from a Scottish local authority teaching them the fundamentals of project management.
Having introduced myself as having formerly been both a “solutions” and “enterprise” architect in previous roles, one of the participants on the course responded quite angrily that he disliked the way in which people in IT called themselves “architects” when he had trained for seven years to become a real one.
I think I managed to get him back onside by talking about how IT had appropriated the term as a metaphor in adulation of the skills that our building-designing friends display, but it’s important to remember above all else that it is a metaphor. Technology architecture is an exercise in planning, documenting and replanning the way in which either the technology itself, or more usefully, a business combines together various pieces of technology to support and enhance the way in which it operates. Think of it like the various plans, drawings, details and lists that a building architect would create to not only get a building built in the first place, but to allow for its continued maintenance in the future (possibly, it has to be said, not only the job of the architect).
There are many different flavours of architecture in the world of IT:
enterprise architects define how a business, its processes, its information and data all fit together at a macro level (to stretch the analogy, almost City planning);
solutions architects define how a particular system should be designed and built (both in term of how the software works, and potentially what devices and services should be used to build it on);
data architects map how information exists in the world and then construct abstract models that allow computers to process that information in meaningful ways;
information architects define how people can navigate around systems (a term that came to prominence with the rise of the Web);
network architects get into the plumbing of how the wired and wireless networks on which we rely operate and inter-operate;
and the list goes on…
Not much of that should be of concern to most people, to be honest; either it’s too technical to really worry about, or (in the case of enterprise architecture) it’s been made too complicated by a world that seems to thrive on complexity. I’ve worked with both Zachman and TOGAF frameworks as an enterprise architect in the past, and both are utterly confusing through over-engineering. That’s a real problem when you consider that most of what those frameworks are supposed to be for is communicating complicated ideas in a simple way amongst different groups of technical and non-technical people.
I’ll write next about a very simple model that I think could help to define a very practical and pragmatic digital architecture approach. The aim – to help people outside of technology roles make decisions about technology with a better understanding of the short, medium and long term implications.
