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.

 

Posted in: General.
Last Modified: December 18, 2016

Leave a reply

required