Don’t get me wrong.  I’m a strong believer in investing in EA and SA.  But I think it’s important to realize that you can’t deploy either one!  The only thing that you can possibly deploy into a production environment is Technical Architecture (TA).  EA is decomposed into one or more SAs, which are further decomposed into multiple TAs (see Figure below).

At the end of the day, the only thing you can deploy is a new business process, data storage mechanism, software application, sub-system, equipment, etc. at the TA level.  You can’t possibly point to where in your data center your SA or EA lives.  These are merely abstractions that are overlaid on top of the TA deployments and organizational changes that are implemented.

A SA is a collection of TA implementations that are organized around an architectural style and supporting infrastructure.  While it certainly is possible to see Technical Architecture from the perspective of a narrow, single application focus, it is more clearly understood as a broader collective of TA instances that come together to embody the SA design.  In the absence of the SA design and related architectural style, then TA changes and deployments are made in isolation as a random collection of one-off, ad-hoc solutions that are all addressing different objectives within the organization.  The end result is a lack of sufficient traction and cohesion to drive the organization in the strategic direction that it needs to go.  That’s where the combination of TA aligned with SA within the context of EA produces important strategic value – traction and cohesion to move the enterprise from the current (AS-IS) state toward the desired future (TO-BE) state (see Figure below).

Managing the development and on-going maintenance of a Solution Architecture involves the management of a portfolio of TAs.  To do so, you must balance competing concerns both vertically between TAs and the SA as well as horizontally across the portfolio of TAs.

There are three primary tasks to perform in managing a TA portfolio:

1. Highlight synergy between TAs and take advantage of this synergy
2. Resolve resource conflicts that arise between TAs and ensure that activities are properly prioritized and managed
3. Align design strategies so that patterns and supporting components do not conflict with one another

So remember, in order to be effective at delivering enterprise value through investment in architecture, then you need to focus upon architecture governance.  Proper governance can guide your TA implementation efforts to align with another another, align with the SA design, and ultimately realize the long-term EA vision through multiple TA increments.

• Should an architect get certified? 
• Should a hiring manager insist upon only hiring certified architects? 
• After all, wouldn’t you prefer to work with someone that has proven to some independent 3rd party that he or she is a credible and capable practitioner in their respective field? 

If we were talking about being an electrician, a plumber, a network engineer, or anyone else that is operating in a non-volatile environment in which requirements, solutions, techniques, and best practices are a relatively static set of known values; then I would absolutely encourage you to work with only certified personnel.  The Business and Information Technology arena is, however, constantly changing in terms of practices, frameworks, techniques, tooling, technologies, and strategies.  What constitutes ‘state of the art’ best practices is a moving target.  Furthermore, Business and Information Architecture must, by necessity, be aligned with the goals, constraints, and differentiators of a particular organization.   Certification at a generic industry-level simply cannot account for such organizational-specific nuance.

What does it mean to be certified?

Simply put, getting certified means that a 3rd party has determined that you have the requisite knowledge to operate in a given capacity.  Some certification programs even go so far as to require proof that you have actually applied this knowledge to your field for a given period of time.  Certification can be used as a benchmark for gauging an individual’s grasp of a particular domain of knowledge.  It can furthermore be used as a hiring criteria to quickly sift through candidates.

Is there any sort of guarantee that comes with certification?

The only guarantee that certification provides is that the individual in question is very good at learning a body of knowledge and answering questions.  There is no guarantee that this individual has successfully retained this knowledge beyond the scope of the test.  More importantly, there is no guarantee that this individual is actually able to put this knowledge into practice consistently in the design and development of a solution. The practical application of knowledge to a given situation and the honing of skills and techniques on real world projects is the true measure of someone’s capability.

What is the purpose of certification?

Take one big step back and ask what the purpose or motivation is behind certification.  Two words – lower risk.  Requiring certification is simply a way to reduce the risk that the personnel working on your projects will do a lousy job.  If you return to the earlier argument that the Business and Information Technology arena is dynamic, evolutionary, and fiercely competitive, then the prospect of requiring a generic industry certification does little to reduce risk.  To truly reduce risk on your projects, you need a way to certify that someone is prepared to contribute successfully to your organization’s approach to architecture.

Rethinking Certification

I work with businesses, government agencies, and non-government organizations of all shapes and sizes.  With few exceptions, everyone is taking a custom approach to architecture and solution development:

• TOGAF, but trimmed down to the bare essentials [a large healthcare technology services firm]
• Zachman + TOGAF + FEA Reference Models + a custom set of solution techniques [a mega insurance carrier]
• TOGAF, but trimmed down to the bare essentials + RUP during Phase G of TOGAF [state government agency]
• Customized RUP for most projects, Waterfall for a low risk projects, SCRUM for everything else [transportation company]
• Custom solution life cycle, RUP for SW projects, BPM + Six Sigma Processes for non-SW changes [defense contractor]
• TOGAF + Zachman [oil & gas exploration firm]
• I could list more…

What’s the take-away?  For an individual, getting a certification might make you more marketable.  For an enterprise, the value of generic certification is pretty sketchy.  What really matters is that you can lower the risk that personnel will not understand your custom approach to business, technology, and architecture as a whole.  You want teams that know your approach and can successfully apply it on real projects.  The only way to accomplish that is through a custom education process that consists of classroom learning, role-specific certification that is tailored to your processes and approach, and culminating in an apprenticeship-style mentoring program.  Learn it, test it, do it, and then teach it to the next generation.

TOGAF Building Blocks Background

Building Block Uses

• Defining the baseline architecture for each domain
• Defining the target architecture for each domain
• Populating the repository with reusable assets
• Retrieving previously vetted assets from the repository
• Performing a gap analysis and producing a roadmap of building block changes to evolve the architecture landscape
• Identifying solutions (SBBs) that map against architectural functionality (ABBs)

Building Block Characteristics

• A package of functionality defined to meet the business needs across an organization
• A building block has published interfaces to access functionality
• A building block may inter-operate with other, inter-dependent building blocks
• Considers implementation and usage and evolves to exploit technology and standards
• May be assembled from or a subassembly of other building blocks
• Is reusable and replaceable

TOGAF Specification References

• Initial, conceptual introduction to building blocks in Chapter 2, Core Concepts
• More thorough, complete treatment of building blocks in Chapter 37, Building Blocks

Building Block Implementation

I have defined Function Blocks (FBs), Infrastructure Blocks (IBs), and Utility Blocks (UBs) as a tangible implementation of TOGAF’s ABB and SBB concepts.  I collectively refer to this as the Function Block technique (although supporting Infrastructure and Utility blocks exist as well).  The intent of the FB technique is to provide a concrete instantiation of TOGAF’s building block concept in the form of a descriptive template, BPMN and UML diagrams, and supporting tables, lists, interfaces, and association / dependency references.

FBs allow a system designer to construct solutions in a modular fashion.  It allows systems to be defined in terms of logically connected modules that are capable of running on different processing resources.  Complete applications, can be built from a collection of function blocks, formed by interconnecting their inputs and outputs.  Functional Blocks are intended to improve productivity in terms of re-use, reliability, flexibility and interoperability.

Use Cases / User Stories / Business Scenarios and applicable requirements are connected to FBs / IBs / UBs.  Functional Blocks are self contained work units that have direct co-relation to the use cases and  functional requirements developed during the business architecture phase (Phase B of TOGAF’s ADM).  Simple blocks might only map to a single Use Case (UC) while more complex blocks may map to multiple UCs.  A given UC can map to multiple blocks in order to fulfill all of its identified functionality.

Function / Infrastructure / Utility Block Template

• Context Diagram (Provides a high-level visual overview)
• Description (Text-based narrative that introduces the block)
• Core Functions (List of significant functionality as identified by Use Cases)
• Use Case Mapping (List of UC numbers)
• Related FBs (List of other FBs that this one talks to)
• Interfaces (List of data entities that this FB sends/receives)
• Artifacts (Diagrams that support the block definition)

Want to learn more about Function Blocks?  Check out my pre-recorded webinar: A Tangible Implementation of TOGAF Building Blocks.

Lesson #1  Design well-specified interfaces – LEGOs offer you bumps on one side, grooves on the other and they snap together effortlessly.  Purchase cheap knock-offs, or try to combine LEGOs with another building block that is similar, but not the same, and you run into interoperability challenges. The systems architecture within your enterprise is no different. Proper interface design is paramount and your governance model should ensure that this is done properly.

Lesson #2 Modular designs are more manageable – It may seem rather intuitive that any building project (LEGO, a dog house, or an ERP system) should be broken up into manageable pieces. There is more to the story than simply breaking your architecture endeavors into bite-sized chunks. Designing something as truly modular doesn’t just mean you do it in iterations, but that in fact there are discreet sets of capability with clearly defined interfaces that can be inserted / removed / upgraded separately from the entire system. That requires planning, solid interface design, and good architectural governance and design oversight to ensure that the principles of modularity and loose-coupling are preserved within the design.

Lesson #3 If you can’t find it, you can’t use it – Do you remember that one kid on your block that had a massive collection of LEGOs? It was always in a huge bin or trough of some kind and you could build anything with all those pieces. The trouble came when you were trying to track down a particular piece. Needle in a haystack anyone? You would dig and dig and dig to try and find what you needed amongst the chaos. Contrast that with the organization-junkie that had all of his or her LEGOs organized into baggies or separate bins according to color / shape / function (whatever the criteria might be). The second kid might have been obnoxious, but you could quickly locate the piece you needed because of the organization and structure. Correspondingly, the architectural assets that you develop (models, diagrams, services, components, entities, modules, etc.) will get lost in the sea of brightly-colored blocks within your enterprise unless you implement an asset portfolio or similar repository mechanism to track and manage all of these assets.

Governance is Key

The bottom-line is that LEGOs and Architecture share the importance of governing the interface design, governing the modularity and loose-coupling, and implementing a means of organizing and managing the various architectural assets within the enterprise.

This resulted in a really interesting discussion thread on Linked In.

I originally discussed this topic in an earlier blog post – “The Architecture Guidance Counselor”.

The original survey can be found here.

The survey results are available for download – “Thinking like an Architect” (7-page PDF of results and analysis).

I look forward to hearing your thoughts!

Vision for Architects in the year 2000 as conceived in 1910

George Orwell promised us flying cars in 1984.  One hundred years ago, visionary French artist Villemard imagined that machines would construct buildings by following the instructions of an architect (as seen in the above picture).  In modern times we are repeatedly promised that the next generation software will enable business users to build software without the support of IT or enable the system to be auto-generated based solely upon the architect’s design artifacts.  The seemingly endless pursuit of automation leads me to wonder if the human race is fundamentally interested in efficiency and productivity, or primarily motivated by utter laziness?

No matter how you slice it, there is something intriguing and magnetic about the concept of automatically manufacturing something based upon robotically following the design instructions.  It was appealing in 1910 and it continues to be a popular feature that many software vendors aim to provide.  And yet, there is a common observation that seems to fly in the face of all such efforts – human beings and the human thought process is exceedingly complex and difficult to parse.  In other words, you can design and specify and configure all you want, but ultimately, the interpretation and implementation of those design instructions is best carried out by a human being.  That human is capable of applying heuristics and critical thinking skills to interpret and carry out the intended design instructions.

While we wait for androids, flying cars, machines that automatically constructs buildings, and software tools that auto-generate your system implementation and support full round-trip from design to code and back to design, I’ll be relying upon heavy doses of human effort that is augmented and enabled through technology automation.

Approach vs Method vs Technique

First we need to start by distinguishing a few terms and concepts.  We will begin by defining the output of architecture activities.

• Artifact — a diagram (graphic), matrix (table), or catalog (list) which serves as a model for some aspect of the enterprise
• Deliverable — a formal (maybe even contractual) work product consisting of multiple artifacts which provides a complete view of the system or process in question from one or more perspectives

Next we will define three terms that deal with the creation and management of artifacts / models and deliverables.

• Approach — an inclusive term that encompasses the entire set of techniques the an architecture practitioner is applying to a project along with the process or methodology that is being used for combining these techniques into a cohesive strategy for developing and maintaining artifacts / models and deliverables
• Method (a.k.a. methodology or process) — a set of activities that describe an end-to-end workflow for developing and maintaining one or more deliverables
• Technique — a set of procedures that a practitioner performs in order to produce or manage a tangible artifact / model

Understanding Architecture Techniques

Techniques represent the detailed steps that are architect performs in order to develop or maintain a model of the enterprise.  Some techniques may be very specific to the creation of a particular model, such as the Failure Mode and Effects Analysis (FMEA) which is specifically used in crafting the error-handling strategy for the Application and Technology domains of an architecture.  Some techniques may be specific to a particular phase of the project (or occur at a designated step within the architecture process) such as the Stakeholder Mapping technique from TOGAF which is created early in the process (Preliminary Phase or Architecture Vision Phase) or the Business Process Modeling technique which is also utilized early in a project life cycle.  Other techniques are more utilitarian and thus suitable for use in a variety of contexts and project phases such as Pareto Analysis, Cost Benefit Analysis, or Mind Mapping.

The architect is ultimately responsible for determining the optimum technique to apply in a given circumstance.  There may even be a need to apply a particular technique multiple times to solve similar problems that appear later in the project or as part of an intentional and iterative elaboration.  A good example of this iterative approach would be the use of Entity Relationship Diagramming to develop the conceptual, logical, and physical models of the enterprise or system’s data.

Connecting Techniques to Methods

Within the context of an overall process or methodology, the architect must carry out narrowly scoped procedures in order to produce artifacts that demonstrate one or more aspects of either the current or future system design.  Typically a technique will be aimed at producing a particular type of artifact, possibly even conforming to a pre-defined template.  Techniques may exist independent of or serve as integral parts of processes / methods.

Whether a technique is specifically called for by a given architecture process or whether the architect has selected that technique for the project at hand, the incorporation of the technique into the architecture process is critical.  The integration between techniques and processes / methods helps to ensure a cohesive and consistent approach to developing and maintaining enterprise models.

Example Techniques

• Business Process Modeling
• Cost Benefit Analysis
• Entity Relationship Diagramming
• Failure Mode and Effects Analysis (FMEA)
• Gap Analysis
• Intersection / Set Theory Examination (Venn Diagram)
• Mind Mapping
• Pareto Analysis (Pareto Chart)
• Proto-typing
• Stakeholder Mapping
• Story boarding
• SWOT Analysis
• Wire-framing

Technique Rules of Thumb

Learning, applying, and enhancing your collection of architecture techniques is an essential aspect of improving your architecture knowledge and skills.  Recommendations for new as well as experienced architects is as follows:

• Learn and apply as many techniques as you can find
• Where possible, acquire at least two techniques for creating each artifact
• Ensure that you understand and can perform each technique in the absence of a particular toolset that guides and enables the use of that technique
• Identify the advantages and disadvantages of any techniques that you are familiar with to enable you to make good decisions regarding when to apply a technique
• Be cautious that you not develop a set of pet techniques that you apply to EVERY project

The Value of Technique

Although a lot of attention is given to the concept of architecture methodology, the value of techniques cannot be emphasized enough.  Simply put, no artifacts or models would ever get created without the application of techniques.  An architecture method provides an excellent macro-level flow, but it is the mico-level finesse of techniques that ultimately produces tangible artifacts and eventually completed deliverables.

The subject of modeling / design / drafting tools is a touchy one for several reasons:

1. People tend to have one or two “pet tools” that they love and adore and attempt to push on anyone within ear shot.
2. Most of the good tools require a money and time investment.
3. There are a number of tools that are poorly designed, cumbersome to use, overly ambitious in their functionality, expensive to acquire, or all of the above.
4. Architecture practitioners are generally expected to be proficient with all of the currently available toolsets that a client might have recently acquired.

Types of Architecture Tools

• Drawing / drafting equipment
• Modeling and simulation tooling
• Word processing software / writing equipment
• Wire-framing tooling
• Monitoring / measuring equipment

Note: Some methods (as discussed in a previous post), like Six Sigma, include ‘tools’ which are recommended problem-solving approaches and specialized artifact creation mechanisms.  These are actually ‘techniques’ which are mentioned in the same post.

In exploring the subject of Architecture tools, I want to consider the old adage: “It’s the poor craftsman who blames his tools.”  First, we’ll consider the value-added insights that this proverb offers.  Second, we’ll consider the other side of the equation in which it actually might make some sense to blame poor tools.  Finally, we’ll round out our analysis by looking at the proper role of tools and identifying some best practice rules of thumb for consideration.

Only a Tool Would Blame the Tools

A professional in any discipline with sufficient experience and integrity for the profession would not blame tools for poor work products.  It is generally accepted that an architect is tasked with producing quality architecture artifacts regardless of the availability of high quality toolsets.  The architect should understand the enterprise model apart from a tool’s ability to capture and represent that model.  Correspondingly, the architect should be able to capture and communicate that model through any suitable toolset that is made available.  Furthermore, if one or more tools run into problems, the architect should be able to work around the tooling obstacles or even produce a representation of the models using more primitive tools (i.e. produce the models ‘by hand’).  After all, the architect is paid to understand, model, and communicate the architectural vision.  Tools should be treated as enablers not the source of value creation.

It Actually is OK to Blame the Tools in Some Cases

While the conventional wisdom of ‘not blaming the tools’ has a considerable degree of merit, we have to be realistic about our expectations.  First, enterprise business processes and the corresponding information models are complex animals.  Secondly, there are some truly awful and/or cumbersome tools out there that make the job of capturing and managing such models more complicated and unreliable than is necessary.  Combine this with the fact that the tools which have been made available to an architect may not be the most appropriate tools for the job that the architect has been tasked with completing.

Viable Reasons for Blaming the Tools

• A new tool is being forced on the architect without sufficient time for ramp-up and/or acclimation
• Multiple, disconnected tools are required for use and they are unable to preserve traceability and / or synchronized maintenance of the models
• The available tools are not designed to complete the tasks at hand
• One or more tools are broken and/or unusable
• The performance of the tool is not up to par for the volume and/or pace of work expected

Proficiency and Productivity Are Undervalued

What is often overlooked in the discussion of tools is that there is real, tangible value in equipping your personnel with tools that they are proficient in and which increase productivity.  A good tool won’t make up for an incompetent individual, but it can help to guide and enable a novice practitioner.  More importantly, in the hands of a skilled architect that is proficient with that particular toolset, a good tool can result in a dramatic improvement in productivity.  Increased productivity translates into real dollars in terms of project timelines and resource utilization.  The costs associated with tool acquisition and implementation certainly need to be careful weighed against such productivity gains, but the impact to the pace of artifact creation / review / maintenance, should not be overlooked.

Architecture Tools Rule of Thumb

The use of tools in the practice of architecture is a necessary component of applying techniques to produce architecture artifacts.  As such, it is important to identify and select a collection of tools that will provide more value than they cost to acquire and use.  The following best practices are recommended regarding the use of tools:

• Develop deep experience in at least one tool within each category / type identified earlier.
• Gain foundational experience with multiple tools in each category so as to properly compare / contrast and to aid in the selection of optimum tools for a given problem domain.
• Avoid dependency upon a tool, ensuring that you always understand how to develop artifacts from scratch or at least how to develop them using a more primitive tool in the event that the sophisticated tool breaks or is unavailable.

While the poor craftsman might blame his or her tools in order to cover up incompetence, the failure to acquire skills with a wide range of tools represents a glaring gap.  Rather than using tool availability or functionality as an excuse, a skilled craftsman will tend to have a variety of tools at his or her disposal and select the proper one for the task at hand.

Much of what architects must do centers around that delicate balance between artist elegance and exacting science.  Some describe this as an architecture process while others are more comfortable with the term method or methodology.  Whatever term you use, the method/process employed by an architect is the central thread that ties together techniques, the creation of artifacts, the utilization of reference models, and the application of patterns and templates (all of these elements will be the subject of future posts).  Additionally, the knowledge, experience, and aptitude that an architect must possess is useless if no method or process is employed to leverage those assets in order develop architecture models.

Methods vs Techniques

While a future post will focus upon the subject of architecture techniques, it is important to touch on the subject briefly in order to distinguish the concept from that of process or method.  A technique represents a set of procedures that a practitioner performs in order to produce an artifact.  A method, on the other hand, represents a set of activities that describe an end-to-end workflow for developing one or more deliverables.  Throughout the method, the identified activities may involve the use of one or more techniques in order to produce required artifacts.  These artifacts will then be combined together into the deliverables being produced as a part of the larger method / process.  For example, when making a PB&J sandwich, the process that you employ might be to first get all the required ingredients out on the counter, then apply peanut butter to one side of the bread, jelly to another, assemble the sandwich, then cut it, and finally to dispatch it (to a plate, a bag, your mouth, etc.).  Throughout that process, there were several techniques in play – one for how you apply the peanut butter and the jelly, another for how you cut the bread (halves, quarters, angles, etc.), and another for how you dispatch the sandwich (plate / bag / mouth).  The individual artifacts would include bread with peanut butter, bread with jelly, a complete sandwich, a cut sandwich, and a plated / bagged sandwich.  Then the final deliverable would be the hand-off of the completed sandwich to the customer or stakeholder.

Architecture Process / Method Examples

There are quite a few architecture processes and methodologies to choose from.  The following is a list of some of the more common architecture methods.

• TOGAF Architecture Development Methodology (ADM)
• Rational Unified Process (RUP)
• Waterfall System / Software Development Life Cycle (SDLC)
• Agile (Scrum, eXtreme Programming (XP), etc.)
• Six Sigma’s DMAIC and DMADV
• Test Driven Development (TDD)
• Model Driven Architecture (MDA)

Note: These approaches come into play at varying levels of scope and depth.  Some are quite all encompassing (like ADM and RUP) while others are bit more narrowly focused (like XP or TDD).  The various processes and methods overlap, some have synergy, and others are necessarily mutually exclusive.  The key here is to understand the relative strengths and weaknesses of the different approaches and select the right one for a given project.

Choose the Right Method for the Job

It is important for architects to have a command of multiple options / approaches, even if you might have a general method that you apply most / all the time.  Even if you do have a favorite or typical process you employ, by being exposed to multiple approaches it gives you more context and a better sense of the options available when tailoring and/or simply executing the process/method that you tend to use.

A significant area of focus for an architect centers around the processes and methods applied in the trade of architecture.  Some architect’s choose to specialize in a single approach to architecture.  Others will develop a vast range of processes and methods, selecting the appropriate one for the job at hand.  Processes / methods can be formal or informal, involve zero or more iterations, and run the gamut from simple to extremely complex.  The application of processes / methods enables the architect to produce and maintain consistent, reliable models of the enterprise.  These models elaborate one or more domains at varying levels of abstraction (conceptual / logical / physical), providing a glimpse into one slice of the overall system.

Architecture Method Rule of Thumb

• Learn at least one architecture method / process extremely well
• Learn about other approaches and gain hands-on experience in at least two other methods / processes
• Develop a ready awareness and comfort level regarding the relative strengths and weaknesses of the different architecture methodologies at your disposal

In walking that fine line between art and science, architects can take comfort in knowing that there are multiple well-developed and robust methodologies available for use.  Those architects that prioritize the learning and practical utilization of multiple approaches to developing architecture are more likely to be successful in their architecture design and implementation activities.

There are two key elements at work here.  First, there is certainly a need to develop knowledge and experience in key areas of the industry as well as a particular enterprise in order to be effective as an architect.  I blogged about this recently when I described the importance of knowledge and experience in different aspects of architecture and then again when I wrote about the value of having a broad background in multiple project roles.  So the notion of growing into an architecture role certainly has some merit at first glance.  But the second consideration is that not everyone necessarily has the aptitude that would be conducive to an architecture profession.

Finding Your Path

If someone were to consult a guidance counselor regarding employment in the field of enterprise / solution / technical architecture, then that person’s interests and aptitudes would be an important factor in steering toward a fulfilling and rewarding profession.  Instead, there seems to be some sort of assumption on behalf of most information technology professionals that it is somehow a foregone conclusion that everyone eventually wants to or should aspire to become an architect.

The truth is that not everyone would be happy, fulfilled, and/or equipped for success in the role of an architect.  All too often individuals are promoted into an architecture role because they are so talented in their current capacity as a business analyst, requirements manager, application developer, database modeler, or system administrator that the next logical career move is to become an architect.

The role of an architect is NOT a standard promotion that is bestowed upon someone based upon exceptional performance, technical proficiency, or as a part of a standard career progression that everyone mechanically moves through.

Know Thyself

The role of an architect requires some unique qualities that not everyone necessarily possesses.  Education and experience can certainly enhance one’s capabilities, but there is a fundamental set of qualities that are needed in order for someone to be successful in the role of architect.  Architects must be:

• proficient communicators (oral, written, and technical)
• comfortable with abstraction (preferably multiple levels of abstraction)
• able to collaborate with and lead a team toward a common solution

Individuals that are poor communicators, prefer concrete scenarios, or are more comfortable being measured as an individual rather than leading a team, are likely to be frustrated and unsuccessful in the role of architect.

Time To Dust Off The Piano

I was speaking at an EA conference recently and I had the distinct honor of chatting with John Zachman about this very topic of architecture aptitude.  He posited to me that there is a very strong linkage between architecture aptitude and musical aptitude.  On an expert panel a few years prior, the question arose and he discovered that every member of that particular panel had multiple years of musical training.  Then I recently had a conversation with a respected colleague at a large health insurance client of mine.  He is a senior architecture practitioner (who was a music major in college and previously studied linguistics)  and he indicated that in his many years of experience, a disproportionate number of technologists and especially architects are skilled and/or training in music, linguistics, and mathematics.  What’s the connection amongst music, linguistics, mathematics, and architecture? Two words – abstraction and patterns.  Zachman mentioned one other clue to me as well.  He said that he has found that architects tend to be very comfortable thinking in terms of metaphors.  Metaphors are just another form of abstraction!

All of this is just anecdotal evidence, but I am working on getting a clearer picture of the connection.  If you are an architect practitioner and would like to participate in a brief survey on the topic, please answer the following questions: Architect Background Survey

Survey Results Posted (6/1/2011): http://archvalue.com/?p=216

Aptitude Rule of Thumb

• People that thrive on interaction and collaboration TEND to be good architects
• People that enjoy analogies and metaphors TEND to be good architects
• A surprising number of architects are also musicians, linguists, and/or mathematicians (not exactly a causal link, but there seem to be a lot of similarities in the way architects and musicians/linguists/mathematicians are wired)

I don’t know if there will be any guidance counselors steering impressionable young minds toward the field of information architecture any time soon.  We can, however, begin to recognize within enterprises that the role of the architect requires some unique qualities that are not necessarily possessed by anyone.  Just like you wouldn’t want a project manager that is bad with administrative work and has a tendency to procrastinate, you will be ill advised to hire or promote someone into an architecture role if this person was a poor communicator and far more comfortable dealing with concrete elements rather than patterns and abstractions.