Every now and then I get a question asking about how enterprises develop without an enterprise architect. For example, there are many new startups and many established companies that don’t have formal architect roles. Then there are companies like Amazon, Google or Facebook that have grown at an astonishing rate over the last decade or so – apparently without an EA masterplan to guide them.
Interestingly, if you look on LinkedIn you will find that some of these companies have people working for them with the title, “Enterprise Architect”; but there doesn’t seem to be much evidence to show how EA has been used in these companies.
Thinking about this led me to create a new model – which I have currently given the rather clumsy title: the Sensing – Learning – Exploring – Breaking (SLEB) Model.
It is related to one of the fundamental factors in EA – Knowledge. I included knowledge as one of eight factors that are fundamental to EA because EA is highly dependent on the knowledge of architects, stakeholders and users. Some EA approaches overlook the fact that much of this knowledge is implicit – in other words, we don’t explicitly describe a lot of the things that we “know” about the components, structure and behaviour of an enterprise architecture.
Similarly, there are many people who have an implicit understanding of the concepts and techniques of EA. If you compare this with gardening, there are plenty of people who have a garden that are not formally trained as gardeners; they still know a lot about the subject, and create wonderful gardens. There are many people who implicitly know basic concepts in EA. For example, patterns for grouping EA building blocks such as sequential, layered, or networked combinations of components and interfaces; or behaviours, such as the organic way that some components evolve – for example, “customers who viewed this item also viewed”, or the ever-changing priorities of an item based on social media activity.
Back to the SLEB Model, which describes an ever-repeating pattern of how we learn about Enterprise Architecture (it may even apply to how we learn about anything):
- We start by having a sense of how to do something. This is a natural or intuitive grasp of a topic. It is what we know when we are untrained. But our sensed knowledge might be quite sophisticated and detailed… someone who isn’t trained might still have a deep implicit understanding of how to go about architecting an enterprise.
- Then we might start learning about EA. This might be through formal training courses, such as a the TOGAF® certification; or it might be through self-guided training (this is the idea behind the monthly subscription for my online training courses). It might involve relearning and unlearning. The key point is that in this part of the cycle we are consciously making the effort to explicitly know more about EA.
- The next stage is exploring EA. What happens here is that you are applying the things that you know intuitively, or that you learned in the two previous phases. As you do this you also start to adapt and extend the ideas and concepts with your own personal experience and skills. It is also here that you start combining knowledge from different sources – for example, you might combine a knowledge of the Zachman Framework with ideas from the Information FrameWork (IFW).
- Finally there is a phase that I’ve called breaking. This happens when ideas that you have previously sensed, learned, or explored don’t provide what you currently need. Years ago I knew about the Zachman Framework, but couldn’t get it to work with the sense-respond architecture being developed by Westpac at the time; I had to challenge the ideas in the Zachman Framework, and change them to create a new type of architecture framework (Information FrameWork). This phase is very important, because the world is constantly changing; so the concepts and ideas of the past will not always work for us.
Going back to enterprises that architect without architects…. it is clear that there are enough people with an implicit, sensed, intuitive grasp of EA to create or evolve the architecture. Sometimes – especially with an architecture that is brand new and created totally from scratch – these architectures can be well-formed and highly effective. Over time they will suffer the same problems that face all established architectures – over time parts become incoherent, inconsistent, unnecessary, outdated, over-complex, costly, ineffective, or redundant. They are broken, and so architects need to look at their knowledge of EA and start the SLEB cycle again to figure out how to make the architecture better.
Do we need architects? Yes. Do they need to be labelled and qualified as enterprise architects? It depends… Can we improve the way we learn about EA? Yes. Does this SLEB model help explain all of this? Over to you! Any comments or feedback is always welcome.