Enduring Misconceptions about Enterprise Architecture – Part 2

By Terry Blevins, Fellow of The Open Group, Enterprise Architect at Enterprise Wise LLC

Tackling some key misconceptions about Enterprise Architecture can ease fear, uncertainty, and doubt about its effectiveness. The following list adds to misconceptions presented in Part 1 of this blog.

Misconception: Architecture is just lines and boxes

I have to say I certainly have seen a lot of diagrams in my career and many were just boxes and lines. I called these Neanderthal architectures. And if these were the only type of architectures one has seen, then I understand this misconception and how it would lead one to think that architecture is useless. An architecture with just boxes and lines would be a very bad architecture indeed.

Solution: Text is essential to document architecture

An architecture can take many forms including diagrams, models, lists, textual descriptions, and/or any combination of these. A really good architecture uses an optimal combination of these things to concisely communicate what is needed and its characteristics. If there is any form that is essential, it is text, whether the text is annotating a diagram or fully describing a requirement, it must be used to document architecture.

An example of an architecture documented in only text is the United States Constitution. I contend it is the architecture of the Government of the United States of America. I believe the constitution does a great job of describing what the government need to be and its characteristics. Of course, one could possibly enhance understanding with diagrams depicting the citizen, Legislative branch (House and Senate), Executive branch, Judicial branch, their roles and responsibilities and relationships.

Do not judge an architecture just by its boxes and lines — get to the text. However if you are presented with an architecture that is only boxes and lines, put up a red flag and maybe fire the architect!

Misconception: All architecture is good for is a door stop

Following up on the above, where I propose that an architecture is documented through many forms, an architecture description is indeed a collection of a lot of stuff that if printed out could be a big pile of paper that one might think is best utilized as a door stop. Well let’s just nip this in the bud right off – a printed architecture would be too bulky for a door stop and would definitely be a trip hazard!  So don’t print it out!

OK, maybe I missed the real meaning behind this misconception – or I just wanted to have some fun. But let’s examine what might be behind this misconception. Assertions I often hear are that:

• the architecture is typically out-of-date when it finally gets done
• the darn architecture is too big and not consumable
• it takes too long to get to the point, if there is a point.
• “are you kidding me, you want me to install an architects tool to view the architecture, I’m a CFO!”

I sympathize, an architecture documented in tomes and/or embedded in architecture tools, or isn’t made consumable for a particular type of user, is a bad architecture and maybe a candidate for a door stop (though I still don’t recommend that ;-).  Another point one can make is that the whole architecture is more a tool for the architect, not those impacted, by the architecture. But all architectures aren’t exposed this way – only bad ones.

Solution: Update relevant architecture views dynamically for specific stakeholders

Good architecture content is treated differently, let’s explain how it could be done.

• Specific architecture content is relevant to specific users – that’s the way to communicate the architecture content!
• The architecture needs to be kept current — update views dynamically

To address these two needs, think of the architecture as a giant database – no one consumes the whole giant database. Instead use views based on viewpoints help to separate the architecture in areas that have the interest of specific stakeholders. Update the views dynamically to keep it current. To make architecture consumable, i.e. getting the right content to the right people in the right form, provide reports specific to users for specific purposes.

And a final note – many bad architectures don’t have a “so what” and without a “so what” folk say “why should I care.” The “so what” of any architecture is the list of compliance criteria – no compliance criteria, no interest or even need for interest. With compliance criteria you will get interest, maybe unwanted interest in the form of pushback, but interest none-the-less. Compliance criteria are what makes the architecture relevant to the organization and I am sad to say that I have seen many architectures that did not have compliance criteria – and of course I tripped over many of those architectures as I left offices of very disappointed people.

Summary

After I finished up the last few words above I had an issue – am I using the term misconception correctly? Not sure that I am, but I hope the points get across regardless.

Architecture is different than engineering – or at least should be focused on different parts of solving a problem. If done correctly there is synergy. If both are focused on the same thing, conflict then waste will result.

Architects can be better at their job if they have an understanding of building and/or developing – but it isn’t necessary nor would it be sufficient.

I truly believe that many of the other misconceptions contribute to a notion that architecture is not needed today. I certainly understand that if someone only saw bad architectures that the negative perception would be justified. However if architectures are created and more importantly communicated correctly this perception would wane.

@theopengroup

Terence Blevins, a Fellow of The Open Group, is owner of Enterprise Wise LLC and a semi-retired Enterprise Architect. He is currently a Director of The Open Group Governing Board and an active contributor to the Healthcare Forum within The Open Group.

Terry has been involved with the architecture discipline since the 1980s, much of which was done while he was Director of Strategic Architecture at NCR Corporation. Terence has been involved with The Open Group since 1996 when he first was introduced to The Open Group Architecture Forum. He was co-chair of the Architecture Forum and frequent contributor of content to the TOGAF® framework including the Business Scenario Method. Currently he is excited to help the Healthcare Forum work on Boundaryless Healthcare Information Flow.

Terry was Vice President and CIO of The Open Group where he contributed to The Open Group vision of Boundaryless Information Flow™.

He holds undergraduate and Masters degrees in Mathematics from Youngstown State University. He is TOGAF 8 certified.