A few of us around the globe have been struggling for a while to find a suitable professional headline or title that describes the kind of planning, advisory and ‘architecture’ work that we do. Until recently I might have referred to myself as an Enterprise Architect (EA), from Enterprise Architecture coined by John A Zachman back in 1984. This is still fine for those of us who have our roots in information systems design and are happy to be seen by the majority as something like ‘master information technologist’. However, for those of us who have moved on, applying what we have learnt over the years to broader business issues and solutions, the EA title is now a very loose fit (perhaps more like a throttlingly tight fit!).
So the question is, what is it that we actually do, how do we see ourselves adding value to organisations, and what term most closely describes those activities?
If I look back on my own career of over 40 years, much of this has been spent identifying and planning innovative solutions of some sort, most of which (but not all) have involved the application of information technology, particularly because the control aspect of all human endeavour is largely about manipulating and using information.
For example when I was a military psychologist looking for methods of training tank gunners, my initial approach was to use cameras and film loops linked up to real weapons controls, only later replacing these with computer animations, with simpler, cheaper physical controls to enable gunners to practise the most difficult aspects of the task, such as mentally estimating the 3 seconds delay required between locking onto a moving target and firing the weapon.
The important innovation in this case wasn’t so much to do with the technology but about realising that an acceptable training effect could be achieved more reliably and at lower cost by simulating key learning aspects of the task rather than by having to precisely simulate reality. This is what I call ‘method’ or perhaps strategy, the ‘what’, with the computer system being the ‘how’.
More generally it is clear that many of us are involved in delivering methods to assist with decision making, planning and problem solving. In areas such as: prioritising projects, risk assessment, business process improvement and perhaps process innovation, information management, consolidation of services, data and financial analysis and so on. So generally dealing with a host of decisioning, problem resolution and improvement objectives.
In all of these what I think we typically provide that is of most value are abstracted models that help with understanding the pieces of a problem or requirement, 'seeing the wood for the trees', and related techniques and processes for using such models to achieve an objective, solve a problem, or realise a set of requirements. These models, techniques and processes together constitute methods or frameworks aimed at helping others, managers, designers etc, to implement optimum solutions. In other words we deliver methods to achieve solutions rather than instances of solutions (even though we might also do the latter).
The delivery of methods for achieving solutions rather than just solutions reminds me of that old adage, ‘give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime’. We teach rather than feed.
I notice that even when I am delivering a solution rather than a method to deliver a solution, my approach is still methodical. I will look to develop a framework for my own use, to help pick apart the problem space and represent it in a form that can be logically manipulated to be able to repeatably synthesise solutions.
So rather than Enterprise Architect, which has all sorts of information technology related baggage, I am proposing to use the title ‘enterprise methodologist’, which I think not only leaves behind the IT connotations but also more directly indicates what I and what undoubtedly many of us 'architects' fundamentally provide.