So, I was about to blog on this topic when up comes a Tweet from Ron Schmelzer (@rschmelzer) over at ZapThink, “Question for the tweeple: do Federal EA Frameworks matter? And how do they stack up against non-Federal EA Frameworks? Do Frameworks matter?” Talk about synergies! Obviously, the value of EA frameworks is being questioned by many individuals.
This morning I posted the following comment on the #CAEAP website
“I see there are work tracks that focus on ‘Enterprise Architecture Professional Learning Framework, value to the practitioner’. I think it would be interesting to consider here a move away from a focus on frameworks and a move toward apprenticeship. My personal experience is that frameworks don’t help individuals become architects, it just provides a tools for organization of artifacts. Yet, I believe the industry believes that these frameworks (DoDAF, TOGAF, FEAF, PEAF, Zachman) help non-architects do an architect’s job.”
In my experience, all these frameworks provide a way to think about and organize the artifacts that are part of enterprise architecture, but a framework cannot make you an architect. Additionally, these frameworks provide a means of breaking down the work effort to collect these artifacts, which can be done by non-architects. But, in the end, all these artifacts need to be analyzed against a set of business goals, which then leads to the production of a design that aligns technological direction with the mission of the business.
Which brings up an interesting question, “who is using the framework?” In some cases, the framework has become a bureaucratic milestone on the way to approval. It doesn’t tell anyone who isn’t an EA anything more than what’s been collected about the current environment. There certainly is no way to ensure that the entire current environment is even fully represented by way of the artifacts that are represented. It’s merely a checkmark on some bean counter’s checklist before releasing funds.
If an EA is using these tools, more often than not they are stymied by the lack of support for emerging architectural approaches. As an exercise, try to find a standard way to capture an SOA design using one of the various EA framework approaches. Sure, people are hard at work trying to retrofit these standards to support emerging architectural methodologies, but these approaches take time and are often years behind the industry.
Most importantly is that enterprise architecture frameworks are designed to be tools. A chisel in the hand of a sculptor will yield a work of art, but in the hands of an amateur yields a pile of rubble. The same is true for any of these frameworks. We need to focus on the creation of architects. I believe the IT industry has been remiss in this effort. Sure, they pay for a few conferences, but architecture is something that is culled over time and based on seeing mass of systems being designed and built. I believe instead of certifications, we should focus on apprenticeships. The resume of an architect should read,
“Studied under XYZ from 2004-2006. XYZ has been responsible for … at … While studying under XYZ I was subject to delivery of the following types of systems.”
While I’m on the subject, I believe the same is true for cybersecurity experts.
Apprenticeship is a lost art in the world, which is a shame. Our desperate need for resources today has limited our long term vision of what the IT industry needs to thrive 20, 40 or 100 years from now. Business believes systems can be designed like a McDonald’s hamburger and that developers and architects are nothing more than the lettuce station and the fry station.
Why do we consistently see headlines, such as “SOA Is Dead”, “EAI Is Dead”? It’s simple, because all these things are really complex and you can’t approach them with an assembly line mentality. Forget Henry Ford already, look at Detroit, learn a lesson people! Focus on developing quality, which means selecting those individuals capable of being architects and supporting them through apprenticeship programs. Moreover, support the creation and execution of apprenticeship programs in your organization.
I agree that frameworks don't make architects, but they do help me organize artifacts and not reinvent the wheel. I would also have to agree that an apprenticeship makes an architect. I wasn't part of a formal apprenticeship program but I had lunch a couple of times a week for two, three years with a brilliant man who taught me how to think like an architect. It's been years and many evolutions of technology later but I still rely on the wisdom I picked up to solve the thorniest problems and read the murkiest tea leaves.
I do not know anyone who would claim that a fromework makes an architect. As far as the claim that the frameworks are year behind, I would take exception. Every time I hear the arguement about "try to find a standard way to capture an SOA design using one of the various EA framework approaches" I cringe. This statement in itself shows a lack of understanding of enterprise architecture frameworks and SOA. An enterprise architecture depicts business processes and the systems functions needed to support automation of those processes where appropriate. SOA, on the other hand, is a particular design implementation of the system functional needs outlined in the architecture. To depict an SOA in an architecture is to commit one of the cardinal sins of architecture, which is to define the detailed implementation solution in the architecture. This tendency to want to design the end systems solution in the architcture is a result of the fact that many people calling themselves architects are in reality systems engineers. To build the solution into the architecture is the same as building a system without understanding the end use first. Building the solution into the architecture also results in difficulty down the road in that every time a new IT technology comes along, you need to redo your architecture. It can also result in sub-optimizing your end solution by forcing you down a particular technology path which may not be the best solution to the real needs.
Jeff, talk about text that makes you cringe. I don't know who you bought your SOA training from, but you should ask for a refund! 🙂 Seriously, I realize there's a lot of differing opinions on SOA, but it's not a system design methodology and it has nothing to do with implementation. I used SOA for the design of an organizational hierarchy of a corporation for one contract. Capturing services within the EA effort is more than acceptable, it's a necessity to be successful with your SOA.
I couldn't agree more…It's not "picking the right tool" that matters, it's "developing the right talent." You need to have a mentorship program to develop (and weedout) the right talent. Not doing this right will cause you to justify your (EA) existence constantly…
– Tony
Bless you for this article. We are constantly focusing efforts on forcing processes and forms on people without seeing any useful results. And yet we continue to allow project managers to hire "architects", so of whom don't have the faintest idea of how to abstract, of portfolio impacts, compliance impacts, etc. It's all about the people.
Does anyone know of some resources that define characteristics and talents required of an enterprise architect? Or gidelines on hiring architects? Thanks.
The SOA comments make me think about the whole issue of "what is an architecture"? Yes, we need to capture the services and other components that are part of the enterprise's technology landscape, and yes, you can definitely use SOA principles in many different contexts, including completely non-technical ones.
I like to think of "an architecture" not so much as defining what we have, as defining the underpinnings and structure of the next solution or service – how it should be designed, what infrastructure capabilities it should/should not use, and so forth. Not what does it do, but how it will fit in to the broader picture.
I'd also add that there seems to be plenty of people thinking that a framework makes an architect. Just look at the job postings for architects that have specific technologies and frameworks as prerequisites, as though an experienced architect who has used Bachmann would somehow be unable to be effective using TOGAF. A good architect is one who can, as Esther Posen's comment states, rely on the wisdom gained with previous technology evolutions to deliver insightful solutions in the current technology climate.
Willi, thanks for reminding us about the portfolio impact. Gives me some fodder for an upcoming blog entry. I sometimes get lost in the ivory tower description of EA and forget that the most pragmatic aspect of EA is alignment of the technology assets to form a consistent portfolio. But, perhaps comparing management of technology assets to management of financial assets in this economy is not a good idea.
Whoa!! It's amazing what spirited debates arise from even mentioning SOA. But I think the main point of the article was that mentoring and people/talent building are far more critical than any choice of frameworks.
And I don't consider SOA to be just a framework. I believe that SOA and BPM have the potential to re-invent IT, but not until people throughout the business are prepared to make the changes in process and how we think about software, etc. However, as pointed out in this article, having smart, talented architects is critical to any paradigm. With SOA, ALL the contributers must be smart and talented and willing to unlearn/relearn what they know about IT.
It's the same when people try to implement Agile w/o competent teams. It fails and they point to the Agile process.
Whether it's a framework, SOA, Agile, MDA ,etc….nothing works without the right people. And the only real way to develop people is through mentoring.
Thanks for putting across so clearly an often misunderstood point. Frameworks don't make an architect rather frameworks are tools which an architect use to built on the learnings of others. It helps him focus on the "real" thing. Apprenticeship is a great idea and indeed we are increasingly devaluing it as a great means of acquiring skills. Maybe, because its a time consuming process and IT guys are always running short of time. Software development, generally, requires highly skilled people whether its the architect or the developer or tester to do a good job. Numerous frameworks, processes, guidelines, best practices exists for each different phases and activities and these seem to induce people to believe that these are some kind of "panacea" or "silver bullet" which will solve all problems easily. In reality, all you need is good skilled people and you have solved all your problem in one master stroke.
Sure that classic EA frameworks create some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance). This is one of the reasons for current difficulies with the construction of business systems which match clients' expectations. (I would like to have EA as good as an applied science).
I think that a formal link between enterprise genotype and enterprise phenotype can be done via “enterprise executable model” – EA enhanced by BPM and SOA (see [url=http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation]http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation[/url] )
Thanks,
AS
Frameworks are useful for organizing artifacts and helping to build organizational capability – it allows the architects in an organization or community to speak the same language. However, I also agree that individual capability via apprenticeship is important. Apprenticeship is only valuable if the trade shares common principles or competencies that mentors can use to focus the efforts of his or her apprentice. Has anyone seen a good list of EA industry accepted common principles or competencies that serve as the basis of an apprenticeship program?
As a systems engineer I find the whole notion of architecture at the enterprise level very interesting. As I take course after course on system/software architecture and as an active member a|EA, and a charter member of CAEAP … the theme has always been that the architect creates a architecture to show the "to be" which satisfies the requirements levied by all the stakeholders. That the architect's purpose is to assess and evaluate potentially conflicting requirements to provide an architecture that best provides a "to be" that satisfies all the stakeholders stated needs. If in fact that is the true purpose of the architect, then it renders this discussion on the various frameworks meaningless since a framework is normally used as set of requirements and constraints to satisfy stakeholders' needs. I realize this is almost circular logic but it's not much different from the discussion on whether enterprise architecture is a subset of systems engineering or something completely different. So to my point, EA and SE are subjects where commonly accepted practices can be taught. In addition, students and practitioners can review programs, project and architectures, which show both good and bad examples. The results are a good general understanding of the subjects but both require a period of mentorship so that the information gleaned thorough study and observation can be converted to working productive knowledge. So the question is, where can a budding architect find an EA mentor? CAEAP?
My question is similar to Curtis Barefield.
Where are the mentors, the masters of the trade. In my experience I have run up against the following two obstacles.
1.Wannabee’s
Every systems engineer is an architect and seeing the big picture is just a fad.
2.Arrogance
The ivory towers are so nice, no way they will talk to the peasants.
If Architects are to be taken seriously, then they need to get their heads out of the ignorance (wannabee) and arrogant (to good for ‘those’ people), then we will have this debate for a very long time.
It is time for us, who proclaim to be architects to be realistic to our limitations and very open and willing to share our experience making disciples of truly competent, capable, humble and strong leadership individuals who can help others gain the respect and recognition that Architects truly represent.
I would suggest:
1.Share your experience
2.Make disciples of Architects, who will do the same
3.Don’t let the title go to your head, let your competence and leadership define your title
4.Give, give some more and keep on giving to those who hunger and thirst for the fruits of an Architect
Henk,
Nicely stated. Leadership is a defining aspect of being an architect, although, not a requirement (unfortunately). It is difficult to lead those who believe they have nothing to learn. We've created an environment where individuals can be delusional about their capabilities and there's no signposts or markers to help them reset their state of mind.
I very much agree with the concept of apprenticeship for EA. However, I'm not sure all EA frameworks can be lumped together – TOGAF is primarily methodology, whereas Zachman, FEA and DoDAF are basically taxonomies. With the addition of the Content Framework in TOGAF 9, it now straddles both worlds. For more on TOGAF and FEA, see my blog, 'TOGAF for Feds': [url=http://tinyurl.com/lq4fuy]http://tinyurl.com/lq4fuy[/url]
Excellent discussion of many of the points that I have espoused for sometime. I'd like to add two comments.
First, the confusion with SOA and architecture proper is that SOA is an architectural pattern much as Gothic or Danish modern are architectural patterns and not architectures per se. An important point to keep in mind (especially for SE types) is that architecture is the practice of applying patterns to provide design-to artifacts (not build-to) for the engineers and developers. But I digress.
I, likewise, have come to realize that a true architect will have served an apprenticeship whether formally constructed or not. I would point out that skilled professions still require an apprenticeship. I speak of the practice of law and medicine. Every doctor must serve an internship (another word for apprenticeship) after eight to ten years of medical study. Similarly, lawyers, even barred lawyers, must serve as a clerk (apprentice to a judge) before they may wear the robe. Finally, architects of the civil stripe also work several years under the tutelage of a partner before they may lead a practice. Your point about apprenticing IT architects is more valid that you state.
Thank you for an excellent piece.