Do Architects Have to Have Implementation Experience?
July 21st, 2009
I don’t want to shut off discussion of my last post, but I noted there that another of my open questions about enterprise architecture is:
“Is it possible for someone to be a competent architect without any experience as a practitioner in the implementation medium of the architectures he/she develops?”
Let me state at the outset that my answer to this question is almost always ”no”, and that this is an “informed hunch”, based on my personal experience, but I have no actual data.
The whole point of architecture is to make it possible to make things that are fit for purpose. If it is not possible in some practical sense to make the thing for which an architect has created an architecture, that architecture is useless. Architects cannot simply “throw an architecture over the wall” and insist that its implementation is entirely someone else’s problem. If an architect hands off responsibility for implementation to someone else, it has to be with the assurance that implementation is not only possible but practical.
So the question then becomes “how can an architect be confident that an architecture can be implemented?”
If it’s not based on firsthand knowledge of and experience with the implementation technology, can it be based on secondhand knowledge and experience? Can it be based on education?
Architects can’t be expected to know everything, or have firsthand experience with every implementation technology they might encounter. And while there are many lessons about implementation pitfalls that are largely technology independent, there are too many that are technology specific. Architects can avoid falling into these traps by knowing how to take advantage of others’ knowledge and experience, in particular by asking the right kinds of questions of ”subject matter experts”. My experience has been that the ability to do so is greatly dependent upon having had some kind of implementation experience, and the more and various the better.
Can someone who has no implementation experience of any kind be taught how to avoid specifying an architecture that can’t be implemented? I don’t mean no experience making things; I mean no experience making something that has been architecturally specified, or, more importantly, no experience working with the implementers of their architectures.
There’s a reason many experienced architects disparage theoretical or “ivory tower” architects. It’s because they share the sense that there’s no better way to learn how and why to avoid screwing something up than having screwed something up yourself. It’s why we ask candidate architects what they learned from an engagement, and what they would have done differently. Good architects recognize and exploit patterns, and the best architects recognize and exploit the most general patterns. We can teach people patterns (in this case, patterns of failure), but consistently successful recognition and exploitation (i.e. mastery) requires practice, as we explored in the discussion of my last post, and practice means firsthand experience.
What do you think?
Entry Filed under: About AOGEA
This is a question that I continually ask myself. My observations have led me to a similar conclusion when an enterprise architect needs to communicate architectures down to the solution architects or implementers.
I believe that practical experience (mine is from an applications development perspective so that is the context I am using) is the starting point for accumulating sets of underlying principles and concepts that can be used to assess real world situations, identify reuseable objects and formulate patterns. In fact, a good architect has already applied many “enterprise” concepts and principles at an implementation level although they may have not been cognisant of this at the time. These patterns generally find their way into architectures, at various levels. This is my first point, the best architectures have a real world grounding in that the patterns being applied have been formulated from real world observations and experience that have been coupled with learnings from other sources.
As you state, an architect can’t know every technology capable of implementing an architecture, however, a grounding in the implementation of architectures will allow effective communication and discussion with subject matter experts that will allow feasibility to be determined. My second point is that an architect must be able to effectively communicate architectural concepts with the implementers so that all aspects are “known knowns”. Therefore, this requires an understanding of the target environment to be effective. Then there are credibility issues to be considered in that an architect who hasn’t “been there and done that” has, at times, a difficulty being heard when they attempt to communicate down.
My last point is one that I believe embodies enterprise architecture, the ability to bring all architecture domains together; business, apps, data and technology. Therefore, I think that the question should be posed to encompass all domains. Must architects have practical experience in all these domains to be effective?
To me the key here is your comment about not so much “experience making something that has been architecturally specified” but “more importantly … experience working with the implementers of their architectures”.
Real enterprise architecture is a great deal broader than the standard enterprise IT-architecture stack of ‘business / data / apps / tech’. The best IT-architects do indeed have in-depth experience of most of these domains (with the exception of business, perhaps), but as you say, no-one will have in-depth experience of implementation in every aspect of a large enterprise. So one of the key skills of the enterprise architect is the ability to learn, fast, from others, and to grasp the basic concepts and trade-offs in each domain so as to be able to converse with those who do have the required in-depth experience.
To do that, it’s probable that the architect will need to have some hands-on experience of each domain, technology and theme in scope. But in most cases that won’t need to be much: probably somewhere in the 10-hour to 100-hour range (using the scale in my post 10, 100, 1000, 10000 hours). For example, developing enough understanding of an enterprise to be able to model from scratch its high- and mid-level business functions typically takes some 2-4 weeks, which aligns well with the 100-hour skill-level. But for this to work, the skills and experience in ‘learning how to learn’, in assembling an abstract overview, and drilling down to a usable implementation design for solution-architects, will all need to be at the 10000-hour mark at least: in other words, don’t expect anyone to be a good enterprise architect until they’ve had at least 5 years or so of experience in implementing something across a range of different domains.
The other key personal skill is in managing the balance between forcefulness and humility. You’ll need the latter to be able to listen to others, and to learn from them; you’ll need the former so as to be taken seriously, and to promote and defend your architectural design. That too is a skill that takes significant time and experience to develop - and much of that time is taken up in the painful process of learning, the hard way, the exact extent to which all those idealised ‘ivory tower’ notion work (or, more often, don’t work…) in practice in the messy, complex trade-offs of the real world.
I really like Tom’s comment here : “don’t expect anyone to be a good enterprise architect until they’ve had at least 5 years or so of experience in implementing something across a range of different domains.”
I agree.
It is important to have demonstrated good implementation experience in the past - in line with EA principles and practices (in business or IT) to sufficient scale and complexity to be effective in genuine EA (architecture of the Enterprise, not only of IT).
However - the main part of the EA is one of leadership , advice and guidance so it wouldn’t be the best use of his/her time to spend on implementation matters.
Its a ticky balance - I think it isn’t a bad idea for any EA to keep an active interest in implementation matters (at a reasonably high level) to keep up with with trends and what’s practical for that particular Enterprise.
[… - blog.aogea.org is another nice place of tips. Online Car insurance claims [… -
Your blog is so informative … ..I just bookmarked you….keep up the good work!!!!
I’m Out!
The one thing you don’t want to do is get perceived by either the client or your team as a “Power Point Architect”. You should know, and have hands on experience with the key areas, including networking, security, Windows, Unix, Java programming, and the middleware tools you are proposing to the customer. An architect should also have some working experience with security, availability, and fail-over and recovery strategies, at least for the solution he is proposing. This knowledge should include at least some “hands on” experience.
If the customers starts asking questions about any of these areas, and the architect can’t answer at least the most fundamental questions correctly, it tends to shake the customer’s confidence in the proposed solution.
The architect also needs to be able to come up with work breakdown structures, level of effort estimates, and other estimates, based on the tools being used. If these levels of effort are not informed by at least some level of experience, the estimates could be way off. If they are way too high, it’s likely that the customer will opt for a competitor’s offer. If they are way too low, it’s possible that the delivery team will balk at the schedule and try to push back, which could trigger concern on the part of the customer who may fear that the $2 million project will soon become a $5 million project, with the PM trying to make it up in change requests.
Often, when things don’t go as planned, and the defects start piling up, it’s important that the architect knows what’s “normal” for this type of project and these tools, and be able to give a reliable estimate of how many defects are likely to be found, and how long it will take to fix them.
The architect also needs to be able to adjust the architecture as plans change, requirements change, or as client constraints change. For example, the client might initially want to keep costs down, using inexpensive hardware, but may quickly need to upscale the project to much larger and more scalable servers. If the architect has painted the customer into a corner, such as using Microsoft Windows servers, it limits the ability to transition to AIX on P-Series or Linux on Z-Series.
Very often, the customer knows his business, but he knows he is dependent on the Architect for the successful translation of those requirements to the technology. It helps if the Architect doesn’t have a blank stare when standards specific to that business, such as Edifact, HL7, HIPPA, or SWIFT are mentioned.
Ideally, the client would like to see the Architect creating the code in his mind, so that all he has to do is document it enough to get it implemented by a team as quickly as possible.
I agree with many of the points in this blog.
A good architect needs some implementation experience and at least a high level understanding of the technologies being proposed in a solution to be able to ask the right questions and/or answer questions from clients.
One point that I think has been left out and one that I believe is important to consider is that the architect not only needs to consider the people and skills required to implement a solution but also the people/skills required to support the solution. All too often I have seen good solutions fail or do not live up to their potential because the support teams do not fully understand the technology or do not have the right skills.
The architect needs to consider the support side as well as the implementation to insure that the architecture solution can be supported effectively once the implementation project is complete.