I was perusing my news feed on LinkedIn the other day and came across yet another definition for “Enterprise Architecture” and “Enterprise Architect”. It was offered by a very high-level person at a very prestigious consulting company. It is full of lofty platitudes, big words, and high aspirations. The discussion that followed consisted of people trying to polish the definitions or to tear them apart.

The whole thing struck me as yet another “ivory tower”, academic pin-head approach. Lot’s of words. Complex sentences. Ambiguous meanings. Disagreement within the “community”.

I offer the following:

An Enterprise Architecture depicts what we are, what we want to be, and the course for how we get from the present to the future. An Enterprise Architect is the cruise activities director.

“What we are” is our present state. It includes business goals and processes, technology goals and processes, and the means to measure each. “Who we want to be” is our future state and contains the same elements. The “course” is a gap analysis for each change we need to make on our voyage.

Why is the Enterprise Architect the activities director instead of the captain? Because the EA is not in charge. He makes interesting activities (migration project) available to the passengers and crew and they decide what they want to do.

There is a very interesting article that came across my LinkedIn newsfeed today.  It came via a “like” by one of my contacts.  I can’t tell whether it’s posted to any EA forum.  The theme of the piece is duality.

The premise of the piece is that enterprise architects must possess a dual nature because of two vastly different aspects of the job.  These facets are the need to be a change agent and the need to be a controller.  The post begins with the very familiar lament that EAs are constantly forced to prove their value to their organizations.  I think the tenor of this article is that EA and being an enterprise architect is hard and really exhausting.

The article IS well written.  So are many other articles with which I disagree.

Why does EA and the enterprise architect have to prove their value to their organization?  Most organizations do not pay for functions or for people who don’t add value.  The constant need to defend your value proposition must be terribly exhausting.  It’s also really perilous.  Perhaps it’s because these EA practitioners have an incorrect idea of value.  Perhaps they are using a flawed model for their EA practices.

The job of EA is to understand what the business is trying to do and why and then design strategies to get them there.  The business leaders have done this for the basic business and for any changes they believe are important.  This leads to another question.  Why isn’t the enterprise architect among the business leaders?  Is it because the enterprise architect is really a senior technologist and not a business management type?  I find this to be true in most organizations that don’t have effective EA programs.

Change Agent?

The idea that an enterprise architect is a change agent can really head in a bad direction.  I can see the need to justify one’s existence if the changes proposed aren’t resonating with the business leaders.  Why in the world would an enterprise architect propose a change that has such shortcomings?  Why not work on making those changes the business leaders want happen?  Freelancing trying to find changes that resonate with you and trying to sell them to the business leaders is hard.  They have other things on their minds.

Most enterprise architects frame every change as a technical problem with a technical solution.  Many times an effective enterprise change involves a complex business process.  This process has so many exception paths hung on it that nobody knows what the process is really supposed to accomplish.  Instead of devising a complex and expensive technical solution, an inexpensive simplification of the process is really all that’s needed.

Controller?

I find the controller facet the most troubling.  At this point when the business leaders don’t understand you, you now want to start pushing the technical people around.  I think the real problem with our enterprise architect is that he doesn’t have any friends outside of the EA team, if there is such a team.

If your idea of enterprise architecture has the enterprise architect involved in system construction, you’re not working at the enterprise level.  You’re working in IT and you’re a systems architect or network architect or applications architect.  We need people in all of these roles.  What we don’t need is for them to delude themselves into thinking they work at the enterprise level.  The only way an architect working in the IT department is working at the enterprise level is when the enterprise is in the IT business.  If you work for any other organization with a different business, an IT person is not THE enterprise architect.

In summary, I think this idea of dual nature only serves to complicate EA and the duties of the enterprise architect.  If the architect is REALLY working at the enterprise level, he understands what the business leaders need and why.  He then works to help make it happen for them by working with other architects in lower levels of the organization and coordinating, not controlling. There’s no need to sell what you’re trying to do because the buyers are already bought in and they trust you to devise the way to make it happen.

I have added a Business-driven Enterprise Architecture Principles page to the website http://www.temp.epignosis.com.

Last year I wrote a blog post describing my enterprise architecture principles.  They were written informally as an essay.  I have found myself going back to find them so I can make them available during the time since the post.

I now have formalized these principles, added some points, reworded others, and placed them on their own page.  There is a link under the main menu bar that will take you right to them.

I will be writing blog posts to more fully describe my thoughts and put links one the BDEA Principles page so I (and you) can find them easily.

I had a conversation earlier this month with a colleague, Marc.  He is active in the Enterprise Architecture forums on LinkedIn.  Marc asked me to review some material he had developed for a book he is writing.  We had been corresponding for a while but we decided to conduct a call for a more free form discussion.

Marc’s work will fill a large void in the book of knowledge for EA.  He is working towards definitions of Enterprise and for Enterprise Architecture.  I applaud him for his efforts and respect him for the amount of grief he takes on trying to vet his ideas in a forum with worldwide reach.  There are many people in the EA world who are too deep into the weeds to have a strategic view of the Enterprise, what it does, and how it should do it. Marc’s book will hopefully re-calibrate those discussions.

One thing became evident in our discussion.  Marc and I have different views as to what architecture means.  We both use the ideas of structure, architecture, and documentation when we discuss the domain of the Enterprise Architect.  I use structure and architecture synonymously  to describe the state of the enterprise.  I believe the failings of EA to gain traction in many organizations is that the architects are always trying to define the end state while ignoring the current state.  You will find more about my thoughts here.  The bottom line is I think you need to completely understand your current state before you can move the enterprise to a new place.  You gain that understanding from documentation.

Marc understands structure and architecture to be different concepts.  Structure is the state. Architecture is the documentation.  You can read his work on LinkedIn to get into his development of these ideas.

I don’t think either of us is wrong.  I know that our approaches are different.  As the buyer of EA services, it is incumbent on you to understand what the practitioner is selling and how he will deliver his work products.

Sorry to inundate you with posts today.  I have been using the WordPress app on my iPad to write these posts and apparently it can’t update the blog on the website.  I had to copy and paste the content so I could post it.

I’ll be more timely in the future.

I often see requests on the various forums to which I belong from someone wanting a template or list of best practices for Enterprise Architecture Principles.  I am certain the requestor has visions of some check off the box model or benign fill in the blank model.  He’ll want to know about patterns and stacks and stuff like that.  He’ll want to know about stuff too deep in the organization to be considered “enterprise”.

I offer here my Enterprise Architectural Principles.  He’ll probably be disappointed.

• Enterprise Architecture is a business discipline, not just a technical discipline.  Everything is a business decision.  The needs of the business drive every decision.  Technology decisions must be presented as business decisions.  For example, we need to upgrade the technology in this system because the current technology has known security problems.  These problems are exposed on the public Internet so it’s only a matter of time before we are infiltrated if we have not been already.  The cost of a security breach is at least $300 per customer record lost.  We have n Customer records that could be exposed.  Then there are the costs of the bad publicity and loss of customer trust, and the time we will spend defending against lawsuits.  We have the following options at various price points…
• Nothing matters more than how the Enterprise Architecture supports the business.  Therefore, you must understand what the business is trying to do and what needs to be done to support it.  The Benefit Ratio, Benefits gained / Costs Expended, should be a really big number.   Benefits are gained by the business.  Costs are expended by everyone in the organization and have initial and ongoing components.   These measures can be total or marginal.  Benefits are generally overstated and costs are generally understated.  Be brutally honest in this analysis.  Make sure both sides are audited afterwards to make sure the assumptions were correct.
• If something is defined more than once, it’s not well defined.  There should be only one definition for a process, one implementation of an application that supports it, and one definition for the data element that is used in it.  It’s easy to maintain one set of rules.  It’s really hard to keep multiple implementations of the same rule set in sync.  This applies to systems and to documentation.  This does not mean you can’t have multiple instances of the same implementation.
• Regardless of what your enterprise does, it can be distilled to a single set of essential processes.  I call this the Factory.  The Factory comprises Core processes and is supported by other processes called Safeguards and Exceptions. Core processes are the activities essential to the business’ operations. Safeguard processes are necessary to protect the Factory (e.g. Reconciliation, Audit).  Exception processes allow transactions that can’t worked in the Factory to be completed or made so they can reenter the Factory.  The Factory should always be improved, Safeguards should always be strengthened, and the need for Exceptions should always be reduced.
• Talent always wins over experience.  And talent is expensive.  The uber-talented can grasp and solve many problems in many domains.  They are really expensive.   There is only so much money available to hire the talent you need.  You want the best talent you can get.  Talent is measured by the number and depth of the skills possessed by a specific person that can be applied to the problems you have.  Experience is a measure of survival.  Ask any coach.  Someone you find talented may merely seem experienced to a manager with different problems.  You want talented people who will stay with you because they are happy and well compensated.   It’s true whether we’re talking about technical people or business people.  Some you can afford to hire.  Some you can only afford to rent for a finite period of time.  Understand the difference and spend wisely.
• Your technology stack should be as narrow as possible.  OK, this seems somewhat deeper in the organization but bear with me.  There are multiple business reasons for this.
  • It’s easier to keep track of a smaller number of technologies than a larger number.  Outdated technologies are the second largest set of attack surfaces for infiltrators.  You need to understand everything running in your environment so you can monitor for vulnerabilities.  You then need to patch for them.  Cleaning up everything with one patch is easier than cleaning one thing with one patch and the same thing in a different technology with another.
  • You need talent to manage your business and your systems.  Budgets are not inexhaustible so it’s better to get great expertise and coverage for fewer processes and technologies with the talented people you can afford than to have to scrimp on expertise and coverage for many technologies because you can’t afford enough talented people.  Getting a greater number of less talented people is not a good trade.
• Security is not a bolt-on.  Everyone worries about the functional requirements.  The business generally only wants to pay for implementing their functional requirements.  At the end of the project, or worse after you’ve been infiltrated, people start to worry about security and then try to bolt it on to the existing problem process or application.  Think about security at the beginning and design with those requirements in mind.  The entire enterprise should understand the necessity of good security.  Poor security habits by business (and technical) people are the largest infiltration attack surface.  I have my own recommendation for a security mindset.  Find it here.
• Technology decisions do not drive business decisions.  With everything I’ve already said, you can’t make the business sub optimize in order to meet your technical needs.  If their best solution requires you to expand your technology stack, you need to tell them how that increases your technical staffing needs and operating costs.  This should be reflected in the Benefit/Cost ratio discussed above.   If you increase operating costs enough, the benefits get diluted and maybe what was initially the second choice due to lower benefits now becomes the first choice because it has a higher Benefit Ratio due to a lower total cost of ownership.
• Templates are too specific and Frameworks are too general to be useful.  The problem with templates is they are too specific to allow you to use them to define you business situation.  That is unless you wrote the template because you do understand your business situation.  Since each business situation is unique, it’s really hard to borrow someone else’s template to use for your situation.  Frameworks are like the Pirate’s Code, they’re really just suggestions.  They say you can do this…or not.  How is that helpful?  You could just go through the entire framework and say, “Or not” and be done with it.  What you really need is a methodology.
• You don’t need an Enterprise Architecture; you need to understand the one you have.  Then you need to adjust it to meet the needs of your new business realities.  Too many people think that Enterprise Architecture is a new place.  The problem with moving to a new place is you have to do something with your existing stuff.  You either need to move it too or get rid of it.  You can’t keep it where it is.  It you do then you have only made your environment more complex and more expensive.  Your current Benefit Ratio is your overall profit ratio or similar metric.  It must be at this macro level, it’s an Enterprise Architecture.  The object is to make your Benefit Ratio bigger.