When dealing with architecture, it is important that the context is filled spelled out. And context has multiple dimensions, when some of that is missing, the context may be poorly understood, endeavours may then become disconnected from reality.
It’s really important to remind folks about context, this is a great take at it. The multidimensional aspect could easily be overlooked. Namely, the environment, time continuum, these bring about constraints that help to frame the context, and usually stakeholders don’t have any control over these other dimensions. When some of this is missing, endeavours may become disconnected from reality.
In my opinion, this isn’t stated often enough, instead a lot of debate tend to centre around definitions and the latest-fashion.
Mobile and Cloud represent possibly the best opportunity to reinvent a flagging business proposition. Surveys and studies by many household name analysts such as McKinsey, Deloite and others, point in that direction. In the diagram that I have depicted, ditching Level 3 elements and rewiring Level 2 elements for Mobile and Cloud, that is where the opportunity mainly lies. This necessity of revising and rewiring systems should be a profitable source of business for those who can can into it. Unfortunately, companies that cannot figure out exactly what is going on in their business at its core, will struggle to even see the opportunity. Newcomers who evener even built such Level 2 and Level 3 elements, have the freedom to move along with the market.
It cannot have escaped many software company executives that Mobile and Cloud represent possibly the best opportunity to reinvent a flagging business proposition. Surveys and studies by many household name analysts such as McKinsey, Deloitte and others, show that . My post comes from another angle, a simple observation at a micro level that can be scaled up to a bigger picture.
Actually, I believe that Mobile without Cloud, or vice versa, would not have any significant impact. So, I contend that whenever Cloud is mentioned, Mobile is an implied companion. And the other way around as well. When Internet Of Thins (IoT) finally dawn, Ubiquity would become a more appropriate concept and could encompass Mobile.
I was recently reminded of one pervasive reality with software, dependencies are the cause of a lot of troubles, if not most. I was trying to install a new version of Archi, a software tool I am used to running but hadn’t needed for a while. When it failed to run, I thought I could quickly just rebuild it. I fired up Eclipse and started going through the process of building Archi. I quickly stopped, realising the trap I was slowly getting myself dragged into. What the industry term as legacy is largely due to such dependencies, in many situations, an insurmountable task of rewriting and rewiring code that is large, complex, hard to understand, better left alone as long as it is working. In the case of Archi, I am not suggesting that any rewrite would be necessary, just the dependencies that I would have to deal with before I could achieve my goal, get it up and running.
In the diagram, I name an arbitrary number of levels, or layers, just for this discussion’s sake.
Level 0: this is usually provided by hardware vendors, who make the hardware an then bundle it with software.
Level 1: this is the Operating System level, in the comparison, Microsoft provides this element, this is Windows for example.
Level 2: fundamental building block elements, usually provided by the OS vendor. This is one area where Microsoft open sourced .NET Runtime Engine for example.
Level 3: combines with Level 2 and make it easy to expose system capabilities to users. Level 2 and Level 3 tend to be closely integrated, often case, 3rd party vendors provide Level3 elements.
Level 4: this is the part that the user will eventually experience.
In this discussion, I’ve intentionally left out Apple, as they are known to control the end-to-end user experience in most cases. Albeit, Apple do subcontract for parts and components, embed 3rd party software and open source software, but they control the packaging process. It is not an interesting study for this post, I focus on Microsoft stack vs. open source stack.
I’ve simplified the reality in this diagram quite a bit. But there usually are multiple layers between Level 2 and Level 3. This is where most of the dependency troubles lie. For a developer, this could be a tool chain for example. But it could also be libraries, utilities and other 3rd party software elements. This is where trouble with multiple Windows DLL versions typically occur. Such dependency issues are not confined to Windows, I’ve seen it with many open source Linux software too. The issue happens when for example you are dealing with a Level 3 component and it complains about some Level 2 element that you were not aware of or didn’t expect to be dealing with. That’s the can of worms.
By moving important elements to open source, Microsoft would normally have had to do a lot of work in Level 2 and Level 3, to bring up their open source proposition to the same level where Unix/Linux is at. But, with Cloud and Mobile, this work is not necessary. A wide variety of platforms and legacy systems can be skipped. This is also perhaps the best opportunity for Microsoft to actually ditch support for a lot of systems that won’t need to be directly exposed to the user.
Cloud providers and infrastructure providers offer solutions that combine Level 0 and Level 1. Lots of players have emerged in recent years, providing up to Level 3 either by themselves or by procuring Level 0 and Level 1 from others. Large players like Amazon, Microsoft, and Google provide up to Level 3. In some instances, they offer solutions all the way up to the end user level. Examples abound, I don’t want to extend this discussion too much.
Ditching Level 3 elements and rewiring your Level 2 elements for Mobile and Cloud, that is where the opportunity mainly lies. The necessity of revising and rewiring systems should be a profitable source of business for those who can can into it.
Unfortunately, companies that cannot figure out exactly what is going on in their business at its core, will struggle to even see the opportunity. The situation is akin to old Hollywood blockbusters movies such as Die Hard for example, where it was important to cut the right cable. The comeback opportunity is about separating out what should be dropped from what should be kept, then streamlining the business for Mobile and Cloud. Newcomers who never even built such Level 2 and Level 3 elements, have the freedom to move swiftly along with the market.
To set effective metrics for Enterprise Architecture, don’t look for a magical list that you could just plug in. Instead, you must to develop your own set for this exercise to make any sense. In this post, initially published on Quora, I provide one practical technique to achieve this, it starts with a statement of purpose that you should make people feel comfortable with.
A recent article by Michael J Mauboussin on HBR reminded me my answer on Quora to this same question, so I realised that that answer should really be published on my own blog, and not somewhere else. That is the motivation for this post.
Don’t look for a magical set, you need to develop your own. Here is one practical technique to achieve this, it starts with a statement of purpose that you should make people feel comfortable with.
An effective Enterprise Architecture helps ensure that an organisation spends money wisely, that resource allocation is done in a way that supports your business growth. It should be an instrument for your most powerful decision makers. The scope is massive, this spans every tidbit of information that flows through your way of doing business, it is about your entire chain of information systems (in the widest sense of the term). It goes therefore that you need to know how resource is allocated (respectively how value is created), what the triggers are and how those triggers can be influenced. Your Enterprise Architecture practice must identify and use the levers that control these events and event triggers, for it to be effective.
With the above statements in mind, proceed as follows:
List the metrics that have the most impact/visibility in your organisation’s success, put them in a priority order that makes the most sense to your best people. This works best if you interview and discuss with a mix of key people: people with good delivery track record, people most intimate with your business, and people with powerful decision making power. Don’t look outside your organisation for such a list, you might quickly fall into an anti-pattern trap.
Now armed with your prioritised list, benchmark where you are as you start this exercise, take snapshots of these metrics at regular intervals. Define the intervals to closely match your business activity cycle: from resource allocation to value creation. Start with a high frequency (must be realistic though), and adjust the sampling frequency as necessary, compare the measures every time and with varying sampling windows.
Share the intermediate results you are getting with the people you worked with in Step 1). Try to gather their feedback on the measures that are starting to show, look for trends. Don’t hesitate to change the metric priorities, drop what doesn’t make sense.
As you gain insights into what is driving effectiveness, try to make small educated changes to the metrics, and perform Step 2) and 3) again.
This is rather crude, but if done right, some solid metrics will rapidly emerge for you, and your process in itself embodies an educational and buy-in mechanism, which reinforces your Enterprise Architecture effectiveness.