#architecture #clarity #velocity #direction
If you have the impression that your enterprise architecture is viewed as an ivory tower from the viewpoints of various stakeholders then read on.
In this post, we first try to understand why and identify the causes of the ivory tower syndrome. Then, we will address how to tear that ivory tower down or ideally not even build one. These findings will be picked up again in follow-up posts. Stay informed.
Carrot and Stick
Bonus and fear drive many things, in other words, reward and penalty, carrot and stick. Bonus systems are e.g. used in target agreements promising some factor of a defined bonus when achieving defined targets to certain degrees or percentages. Fear works the other way round, also psychologically, like “promising” a penalty when breaking defined rules, or warning you on risks if not complying to security rules.
Now, in practice, both approaches are typically combined and may vary in terms of weight or focus. Let’s take a look into some examples. The third example might look like being out of line, but I promise you will get the connection and probably also draw some conclusions on your own without further explanation.
Lisa is CIO of passend AG and Jonas is the Enterprise Architect reporting to Lisa. They have a rather small concise set of rules and a community for sharing the transition of strategic thoughts into budgeted initiatives. A lot of projects do already stick to the rules which is mainly driven by sharing services and cutting costs.
Karl is CIO of AusPrinzip GmbH and Julia is the Enterprise Architect reporting to Karl. While they had some quick wins with a target architecture and road map to get there everyday, live has become tedious. Many of the defined rules are broken by a significant number of products (e.g. applications). Jutta can only deal with a few projects at the same time. A lot of executive force is missing not to talk about jurisdicative.
Elena is major of some city in Germany and Johannes is head of urban planning reporting to Elena. There are plenty of building laws and a building authority which employees inspect all building plans as well as construction and finished buildings on site with respect to those laws. Non-compliance gets fined or even brought to jurisdicative.
The first two examples are typical scenarios you may find in any industry while scenario 3 stems from urban planning – constructing cities, streets, and other infrastructure that we are so used to. While some concepts from urban planning cannot simply be transferred to enterprise architecture, we can understand and learn a lot by comparison from this more mature discipline. Roughly, enterprise architecture is to software architecture what urban planning is to construction planning.
Analysis of Scenarios
While scenario 1 rather reflects a sunny day, scenario 2 comes with a lot of dark clouds, metaphorically speaking. But, why is this?
Well, rather than focusing on more wins after the quick wins, Julia gave in to the grand idea of having an architecture law from §1 to §999. So beautiful, but unfortunately doomed from the beginning to be only a paper tiger. If you are neither providing for an adequately equipped “building authority” nor a jurisdiction, you’ll end up toothless.
Without adequate authority you do not have sufficient control.
Without jurisdiction you can neither dispence justice nor punishment.
What are the options for improvement?
- Create an adequate authority.
- Cut down architecture laws to a few.
- Balance authority with architecture laws.
- Combine authority with other disciplines like revision, portfolio, security, quality management.
- Mostly forget about jurisdiction.
- An enterprise has no internal jurisdiction.
- You might integrate with revision, but revision only recommends actions to executives which in the end can cut budgets as interpretation of punishment.
What else can you do besides authority and jurisdiction?
- Align with objectives of managers.
- If you succeed in implanting architectural objectives as personal objectives for managers then you create a win-win situation.
- Implement cost saving services for architecture laws
- E.g., you would like to enforce some software like CRM as standard to use for a defined context like customer care.
- Ensure a good contract with the vendor.
- Set up scalable infrastructure.
- Provide licenses that make projects happy (cutting costs).
- Build up know-how.
- Include employees feelings.
- Learn from good management principles.
- Things in a company mostly work well because of well motivated employees.
- Make the doers feeling great about their work by making their work visible and showing their relevance.
- Easy example nowadays: your cloud gurus.
- Make one or few architecture laws with them together.