Again, it’s theory versus practice
In theory, enterprise architecture is wonderful. In practice, it’s not. And the practice is not getting better. Hence my premise: “Enterprise Architecture Is Dead”. Our business executives don’t care about our theory. They care only about practice. The reality. Results.
For every company doing “world’s best practice” enterprise architecture (there are a few), there are 999 companies stumbling along in the dark, doing the best they can. Dead.
“And what constitutes ‘World’s Best Practice Enterprise Architecture’?” you ask…
Well, you may not be surprised to know that topic has been kicking around for years…
Hold my beer. Here I go. Again.
Architecture Maturity Model
The concept of an “architecture maturity model” is relevant.
Recall that I said “enterprise architecture is dead”. I said this because — with notable exceptions — most architecture teams perform at a low level of architecture maturity. Here’s what that looks like.
Hallmarks of Not Enterprise Architecture
If we were to describe an architecture function that is performing at a relatively low level of maturity, what would we see?
Herewith I propose a few “Hallmarks of Not Enterprise Architecture”. (I’m going to run through this without getting into detail.)
The Name Doesn’t Really Mean Anything
- The job title “enterprise architect” can mean anything. It’s often almost an honorary title, denoting a senior solution architect. The job title may have been created by Human Resources: “We’d like to keep you, but we can’t pay you any more than we’re currently paying you. How about if we gave you an important-sounding job title, like Enterprise Architect?”
- The name means “A staff architect who can be assigned to support any program or project anywhere in the enterprise”. Enterprise architects provide guidance to program and project solution guidance. This is pretty much all they do.
No Architecture Skills Framework
- If the job title “enterprise architect” doesn’t really mean anything, then you will not find a well-thought-out, performance-measured, architecture skills framework.
- Of course, none of the architects have any skill or interest in business architecture. “What the business do with the business solutions we deploy is up to them to figure out.”
- Generally, enterprise architects have a technology background. If an architect has many years experience in a company, they may think they “understand the business” but really they understand the software applications the business uses. And the history of those software applications. The performance and integration issues. They know who to call to get information — which is useful. But they don’t spend a lot of time listening to business SMEs and the GMs. That’s not their job. Although it should be part of their job. So they don’t really understand business efficiency issues. Gaps. Points of Pain.
No Architecture Practice Management
- There is no Architecture Service Catalogue or Architecture Charter, which explains how the architects work, what they do, what they don’t do. What outputs they create on a consistent basis. How their performance is measured.
- Most architects create only one artefact: the Solution Architecture Definition Document (SADD). Sometimes this is called a “High Level Design Document” (HLDD). Typically this is based on a template — a MS Word table of contents. In reality, there are scores of architecture artefacts (outputs) that should be well defined and consistently produced.
- There are no metrics that measure how well — or poorly — the architects are performing. Some architects say “We can’t measure architecture work. We’re just influencing and guiding. How can you measure that?” In reality, there are hundreds of things that can be measured. Too much to get into here.
Architecture Governance
- Even in organisations that have “enterprise architecture in name only” — there are technology standards: “We can only use MS SQL Server and Oracle for RDBMS”. There are also typically architecture principles. Mainly “Reuse before buy”.
- Unfortunately, it seems to be a common practice that programs and projects define their own technology standards and patterns. And their own architecture principles. Which makes things awkward indeed.
- So architecture governance is a matter of persuasion rather than building solutions that leverage a genuine strategic architecture framework or roadmap.
- Architecture governance is reactive: “Why did you do that? You can’t do that! You should have asked us before you did that!”
Architecture Knowledge Management
- There is no consistent team use of an architecture repository or architecture modelling techniques. Individual architects may use a modelling tools for creating diagrams, but the work of multiple architects is not additive. Each architect does their own thing.
- The architecture repository is SharePoint. Architecture modelling is PowerPoint and Visio.
- There is no team agreement or common use of a consistent architecture meta model. Some architects use (or try to use) UML, some use BPMN, some use Archimate, some use boxes (and boxes within boxes) and lines and arrows. Some architects use little cute graphic symbols. There is no “common language” for architecture. Which can really slow things down, and hides fatal flaws, gaps, and misunderstandings.
Program and Project Views Only — No Views of Enterprise
- The architects create whatever documents and diagrams they need to inform programs and projects. But the “enterprise” is more than the sum of all programs and projects. Lots more.
- So if there is no “Enterprise Business Capability Map” (for example), I know they’re not enterprise architects.
Architecture For Architects. Only.
- Architects sometimes create diagrams (artefacts) that they call “enterprise” views of things. But few people other than architects ever see these views. Even the above “Enterprise Business Capability Map”. When you ask a non-architect (ie, a business unit General Manager) if they’ve seen the “Enterprise Business Capability Map”, they say: “The what?”
That’s enough for now. I’ve just skimmed the surface. Ask me if you’re interested in any specifics.
If any of the above “Hallmarks of Not Enterprise Architecture” sound familiar, you may be a dead enterprise architect yourself. Or you may know one.
The fact that anyone knows — or thinks they know — what great enterprise architecture is — theoretically — is of not much interest to your business sponsors and stakeholders.
In theory, I’m rich and handsome. LOLZ.
