One of the things that I have observed over the course of this century is the transition away from traditional “Data Processing” titles like programmer, programmer analyst, systems analyst, etc. The key evidence of this trend is the proliferating of self-aggrandizing titles involving the term architect. In 1985 when I graduated, I don’t remember every hearing of a software architect or a network architect, or God forbid an enterprise architect or an application architect or a solutions architect or any such thing.
I suppose it started with the transition from Mainframe style computers toward what we now refer to as distributed systems. First everything was mainframe and dumb terminals, then it was PC’s. Then it was networks of PC’s and Servers. For a while it was Client/Server and then multi-tier or n-tier and finally the generalization of the term distributed systems. Different computers doing different parts of the work in different places, mostly by “collaborating” with each other.
The programmers who worked on distributed systems had much more diverse titles. They were software developers, application developers, database developers, user interface developers, and with the advent of the internet and the world wide web, there were web developers. Back in the day, there were programmers who worked on the internals of systems that no user would ever see. Those people were called systems programmers, now in the age of distributed systems, their new self-aggrandized title was software engineer! Then as these servers and n-tier platforms started to become more complex, every server product needed a dedicated administrator so the unix operating system need a unix admin and the database needed a database admin and pretty soon we had java “containers” that needed their own admins. The networks that connected all the computers together needed administrators and pretty soon the whole thing got very complicated.
As these systems grew more and more complex, we started to realize that the genius-wizards who were good enough at their job to be able to see the big picture and to help us straighten things out when they got wrapped around the axle deserved a special title “Architect”. This brings me to the ultimate question for this blog post:
“What the hell does an architect have to do with information technology?”
That makes me want to go back and unpack what an architect is. The word architect, derives ultimately from the Greek arkhi (Chief) and tekton (Builder) – so the architect literally is a chief builder.
When you look up architect the usual definition is: a person who plans, designs, and oversees the construction of buildings. To practice architecture means to provide services in connection with the design and construction of buildings and the space within the site surrounding the buildings, that have as their principal purpose human occupancy or use.
Of course, when you go to an architect’s office, what you realize that even an architect is just a glorified draftsman. When you sign up Skidmore, Owings & Merrill to design your office building there will be 30 “architects” assigned to work on your project – but only one will be the chief. All of them have degrees in architecture. All of them are licensed professionals. Only one is the chief, the rest are tribesmen.
Usually only one architect or a small group of specialists work with the client and help the client make good decisions, while back at the hive, all the worker bees crank out all the detailed drawings and layers for the different views and trades.
So why did we in information technology decide to use the term architect to describe our most capable folks? Surely we had other choices? We saw at one point the adoption of engineer in relation to systems programmers. In the nineties, a lot of programmers called themselves software engineers. It was at that time a clear step above the programmer. Yet now, almost nobody calls themselves a software engineer. Anyone who does is designated a relic of a darker time.
I think it goes back to the rarity of that title and the value of having a rare title. Remember, titles are often granted in lieu of bonus or pay raises, so they are an important part of any incentive package. You can hear the conversation now:
Employee: I was really expecting a decent raise this year.
Boss: Well, the company isn’t that profitable, but you are a really good developer, so here is what I’ll do – I will give you the title Architect and everyone will think you got a big promotion. Just don’t ever tell them that you didn’t get the accompanying pay raise.
Employee: Yeah, that’s fine – at least that’s something and it does look good on my resume so when I don’t get a raise again next year, I can get a better job somewhere else.
Boss: That’s the spirit, what a team player!!! Oh and by the way, you will have the same crappy job description as you always have.
You see, there can really only be one chief builder in a given context. Being the chief implies a certain vesting of decision rights and of responsibility for the success of the endeavor.
Back in the late 1970’s, Fred Brooks, who worked on the OS360 project the decade before wrote a book called The Mythical Man Month which contained the best recorded wisdom of that era about how to build software and software teams. Brooks advocated an approach similar to a surgical team – where there were one or at most two surgeons and the rest of the team were just there to hand them scalpels and stuff. It thinking this through, this also defines a role of the chief builder – although more focused on actually getting results.
In reality, an architect in the technology space is one who can see across all the layers, who understands how things are “fit together” to make a whole thing. The role of the architect is to apply the current best thinking about software construction techniques, available technology platforms and bring the understanding of the customer need so that ultimately the solution is “suitable for occupancy.”
Then there is the other question:
“So why do we care what titles people are given?”
In the end, it is about compensation and the market. When someone has a title, there is an expectation that they will have certain capacity and capabilities. There is an expectation that one can compare compensation and responsibility across organizational boundaries on a relatively level playing field.
Moreover it changes constantly. You can’t stay with the same knowledge base and expect to be employable. When you think of the construction industry and “trades” – plumbing, masonry, carpentry – not a lot have changed, really in the last 20 years. In Information technology – more have changed in the last 2 years than in 20 years in the construction industry.
In information technology, titles are almost meaningless, as they give little hint to what activities and skills and technologies a person has the ability to work in. Yet in this regard, the architect title should have some meaning – as it should imply nothing other than an ability to lead and facilitate the decision making required to complete a software design. One should be able to expect, that an architect should be well versed in all construction materials that might be considered for the job at hand. One should expect that an architect has at least some reasonable familiarity with all of the activities and aspects of working on a software construction team. Finally, one should expect that an architect has the vision to see the construction effort from beginning to end.
In IT, we have architects for every layer or component. We have web architects, database architects, security architects, middleware architects, network architects, etc. In the construction realm that would be the equivalent of having a “door” architect, and a “wall” architect, and a basement architect and a roof architect, etc. It sounds dumb when you say it that way. Or one might specialize by building material, so you could be a Cisco architect or a .Net architect, or a Java architect, or a ruby on rails architect. In construction that would be the equivalent of having a wood architect, a cast iron pipe architect, a pvc pipe architect, a drywall architect, etc. Since that also sounds dumb, they must not be architects.
That leaves me with the concept of “enterprise architecture” and enterprise architects. On the surface, that title, one might think of an architect who has as the scope for his vision, the entire firm. The whole enchilada. But often, that is not the way it works – it is more often than not stopped at only those decisions the affect the whole enterprise. So the enterprise architect is the chief builder of technology things that affect the whole enterprise – but not the less grandiose things that only affect say a single department or a single line of business.
In many firms, the enterprise architects are no longer actually responsible for building things. They create documents that other builders have to read and rules for them to follow. They are relegated to governance. They propose and approve standards that other builders have to implement. In essence they are more like the enterprise building commission. They create and enforce building codes that all the actual builders have to follow. I am not saying that that is wrong, but it isn’t architecture, and they aren’t architects.
I think what is missing from this is the title of application architect. I think an application architect makes sense, because at least in there, it describes something that could be considered a whole construction project. Forgetting for a moment that with todays software patterns, the concept of an application or a program, or a system is much more ambiguous than it might have been even ten years ago. The application architect has the purview of making decisions of construction materials or technology choices and construction techniques or design patterns that encompass a whole thing. I think that today the application architect is the closest thing we have to a real architect in information technology.
I currently work in a group that is called Enterprise Business Architecture, on a team called Functional Architecture. That makes me either a business architect or a functional architect. And with those fancy titles, I suppose that I should be considered a very capable individual indeed. I did some Google research and according to the Internet, a functional architect is a glorified business analyst. A business architect maybe closer as they are responsible for designs encompassing business capabilities, operating model, and technology platform capabilities.
I suggest the following criteria for any architect role to see if it is really worthy of being called an architect:
1) Responsible for building things.
2) Concerned at the macro level with the entire thing being built.
3) Has decision rights (within limits) over design patterns (construction techniques) and technology choices (building materials).
If the role doesn’t have all these three things, it is not really an architect.
I also want to suggest the following criteria for people inhabiting these roles:
1) Have already built at least one thing (application) from scratch.
2) Have a working (not necessarily detailed) knowledge of a broad range of software construction techniques, design patterns, programming languages, and tools.
3) Have experience informing the decisions and coordinating the effort of others who are involved in building software.
If the individual acting as an architect or filling an architect role does not meet these criteria, they are not ready to fulfill that role effectively.
I think that application, functional and business architects are merely modern title inflated variants on what would have been called a “systems analyst” back in the ’70’s… And that, is what I am.