How to get started with Architecture for the Smart Company

In this paper, that will take 15 min of your life, you will learn:

1 – Why Smart Companies needs a strong and future oriented Business and Enterprise architecture capability

2 – What Business and Enterprise architecture is all about in a Smart Company and why that makes me exited

3 – My top 5 advice based upon my sometimes hard gained experiences

4 – Why you should avoid the pitfalls of architectural frameworks

1 – Why successful companies needs a strong Business and Enterprise architecture capability

When capability gap in the Business and Enterprise domain little will happen in the short-term but over time business models, process and tool landscape will no longer appeal to customers, scale poorly nor be future prof and hence hampering business opportunities and driving up the operational cost.

In my experience,  architecture is only discussed at CxO level when significant pressure and change arise (such as: Chapter 11, Turnaround, M&A, regulatory changes, market shifts, sky rocketing IT operational cost) but you are then typically in a hurry and thus not always able to do the proper homework with the ideal team.

In the Smart Company you have a proactive Business and Enterprise architecture capability that reduces the risk for all the above situation happening. As business models and technology also evolve in an increasing pace what was a good architecture yesterday might be undesired legacy tomorrow.

Please note that we need to separate the need of Business Architecture and Enterprise architecture capability from the decision of having an organizational unit with that name. I have seen some sales and business development organisation that drives great Business Architecture even if not a single employee with that title or certificates in fancy architectural frameworks.

(*) Capability = A set of people, process, tools and leadership that can deliver a specific function

2 – What Business and Enterprise architecture is all about in a Smart Company and why that makes me exited

The purpose and the why is the starting point of the architecture

There are loads written on this subject so I do not want to repeat that but still this is really the key responsibility of the architecture function to drive, why not jointly with for example HR as a part of the work is to engage all the company. If you want to read more here are a two good links

– The 5 min readers digest from Smart company – Why Purpose-Driven Companies Are Often More Successful

– The Guru in the domain is Simon Sinek with 4 millions views of his ted talk –Start with the why

I get really exited when there is a clear Why to define and work towards. It becomes especially important when you strive towards self orchestrating teams as key for all to have the same common goal and vision.

It is all about speed and agility

If you can not make it fast do not bother. If you are afraid to fail do not bother. If you are not able to work hypothesis driven without all answers sorted out do not bother.  Many EA practice miserably fail to deliver what the company needs and some of the failure is due to that they are to procedural (“this is the structured process we work after”) and too slow (“if we do not have time to do it properly we will not engage and do it at all)

Do not overcomplicated things, any Lean or Agile type of mindset and attitude will do the work. The fact that the team is working together to create their own framework based on the business needs and organizational maturity are worth more than any fancy framework.

Define where you key pain point are in a back log, asses what information you are missing to make the right call and then as lean as possible gather the data you need to move forward.

One of the best EA architects I have the pleasure to work with has an even more simplistic approach also to the biggest corporate challenges. He will just drive to clearly define what is the critical and urgent issues to solve . with the help of Kanban board he then drills down were needed to get more information and defines any needed hypothesis needed to be validated in order to solve the problem statement.

Technology mastery is essential

If you search for “Technology driven business” you will se that all major strategy and management consultancies will have this in their white papers.

One of the earliest on this subject is Clayton Christensen, professor at Harvard Business School, that predicted this change already back in 2012.

In short you need to make sure your architectural practice is able to monitor mega trends, track where different technologies are on the hype cycle, initiate pilots, build competence and scale when technology is mature enough.

Release the organisations innovation and collaboration potential

Innovation does not happen by itself. You need to build the capability. The methods that fits R&D might not work for the Business or Enterprise architecture. The importance is to define the needed innovation and from there define the best method, approach and resources where sometime you need more of a one-off and sometimes you want to build more of a continuous stream of innovations.

An often missed aspect of Agile and Innovation is to foster a culture of curiosity and eagerness to learn

As part of creating an innovative, open and collaborative culture there is also a need to facilitate collaboration and the establish  self orchestration especially the more decentralized you run the business. Here is also one of the architects key responsibility to systematically collect different teams key concern that is outside their direct control, drive them to conclusion and then make sure all the affected teams are up to speed and implement the latest thinking.

Another aspect in terms of collaboration is also that as complexity increases and problems become multi dimensional you need to pull in the right multi functional competence to get a long-term prof solution. A positive side effect is also that the decision is already anchored and hence faster gets into execution

Transformation and constant change is the new normal

The architectural team needs to also be adept in Business Transformation as great architecture that is not transformed into concrete action has no value. There is a need to work both towards CxO level as well as with the balance of the organization including to measure that change is actually materializing

One simple but yet powerful method is to ensure there are clear and widely accepted architectural principles and guidelines that self organizing teams can use as support during their problem solving and architectural considerations

To break silos a simple but powerful way is to ensure shared key information objects and semantic data objects has a shared definition, clear governance,  architectural principle  and aligned tool including that  information is easily accessible and exchanged.

3 – My top 5 advice based upon my sometimes hard gained experiences

A – Be prepared for that no one loves you or at least that might be the feeling when  you push people or organizations outside their comfort zone into the future. Over time and if you do a good jobb some will start to understand you are one of few that can see around corners.

B – Pick your team with care as you have to gather a multi functional digital native, innovative, collaborative and agile team to get a critical mass moving forward with haze navigating in the internal political minefields

C – You need strong leadership backing as you need to cherry pick the team, challenge the organization including CxO level and not be afraid to fail (preferable fast) so when the shit hits the fan somebody needs to back you up

D – Get the high level sorted out first with Business models, Flows, Processes, Tool landscape, key information object mapped. Ensure it is easy to maintain and shared broadly. The key use is to help communication, understanding and decision-making. Do not map at any detailed level if there is not a clear need for it, but if you do spend the time make it in a systematic and scalable way so other can reuse.

E – Maximize the use of tools, as long as they are helping. You need tool for Collaboration, Portfolio management, decision-making, Agile delivery management, Automated process discovery/mining and mapping, requirement handling, document digitization. Ideally you also need EA tool even if I am fascinated how poor offerings there is on the market.

4 – Why you should avoid the pitfalls of architectural frameworks

This section was originally 4 pages long and I realized it became a paper in itself. In short be careful of all the Architectural Framework and the people advocating them when presented as a one stop shop for all your architectural needs. The often cost much more than the value they deliver and the supporting tools are often even worse in terms of useability.

Management summary from my not yet  (and perhaps never) published paper

• If the architects are not seen helping to drive the business forward their role will marginalize, their influence becomes limited.
• There is no researched evidence, fully in line with my experience, that any of the architectural frameworks (TOGAF, etc) are delivering value, especially outside current legacy when used in full. Of course the framework has loads of toolkits to be used on a need basis
• The key challenge with the frameworks is that the time to map, document and maintain the collected information greatly exceeds the use when you need to solve a concrete problem. In a fast changing world the level of reuse from earlier documentation has a short life span before it becomes obsolete
• EA experts has a tendency to spend too much time discussing the framework and methods and not doing value adding architectural work
• Business and end users are often under represented and/or their input collected by too junior Business Analysts and thus the framework becomes a theoretical model far from the business reality and needs
• Scale Agile is one of few popular framework I think it is worth to get inspired from but it is still not fully matured for a large enterprise (even if that is their claim). One concrete example is that I miss a clear Business architecture perspective as well as drive unmanageable large need to gather the . I also see the risk it is now growing in size and complexity and thus no longer stay as Agile as intended or to quote: “SAFe® the “Fast Food” of Agile”. To read more here is a good guide on when to use SAFe,  A SAFe Class Review for Agilists / Consultants, and finally a critical view on SAFe.