By Terry Blevins, Fellow of The Open Group, Enterprise Architect at Enterprise Wise LLC
I’m not a fan of any Silver Bullet – at least one needs something to propel a Silver Bullet to take down a werewolf. Too many times a Silver Bullet is introduced and people go all in on a belief that it alone is the answer. This is a fatal flaw since ignoring other necessary things turn a Silver Bullet into a tarnished lump of nothing!
Even though I have great belief in Enterprise Architecture, it should not be thought of as a Silver Bullet. Enterprise Architecture isn’t the answer to life, the universe, and everything (we all know that answer is 42). Yet, applied correctly, Enterprise Architecture can be an essential part of an answer.
As a matter of practicality, for Enterprise Architecture to be successful, there are many things that have to work out before, in parallel with, and after Enterprise Architecture efforts result in an Enterprise Architecture. There are governance things going on, there are development things going on, there are operations things going on. Each of these areas can benefit from some good old Enterprise Architecture thinking and, as well, Enterprise Architecture success needs these areas to be successful! Again, Enterprise Architecture is not THE answer, it is part of something bigger.
In most enterprises governance comes in many forms including strategic management, portfolio management, project management, etc. Most of the methods applied in each of these follow some sort of decision-making loop. For example the observe, orient, decide, and act (OODA loop) model informs decision-makers to observe what is going on in an enterprise, put those observations in the right context of the enterprise for the decisions at hand, decide on changes, and put those changes in motion. Another similar model is the plan, do, check, act model (PDCA).
Some of the forms development activities take in an enterprise include employee training, business process re-engineering, lean six sigma, software development, infrastructure maintenance, procurement, etc. Each of these are intended to improve the enterprise in some way. In many cases a single motivation calls for a portfolio of developments across these areas. For example improving customer experience may require development activities to change business processes based on lean six sigma analysis, implement (or change) customer relationship management software, procure and implement new infrastructure to better reach customers.
Operations is where value is created and is directly related to the core business, or mission, of the enterprise. For example the process of making steel, the process of selling the steel, the process of delivering the steel, the process of paying for the steel, etc. are examples of what I consider as operations. This includes real- or near-time operations management activities that aren’t covered under the development area. (The processes of improving these areas is under the development area above.) Examples of operations management include activities that adjust steel making processes based on orders, rerouting delivery based on weather conditions or price of petrol, adjust sales and payments based on resource availability and/or economics conditions.
The enterprise is a whole lot of things, and for Enterprise Architecture efforts to be effective, there must be an appreciation that Enterprise Architecture isn’t just the picture of it all.
Enterprise Architecture doesn’t itself change the enterprise – it is not a Silver Bullet. Rather Enterprise Architecture must fit with a myriad of other processes. It is the job of Enterprise Architects to ensure they do the necessary things to make this the right fit by delivering value and being supportive to governance, development, and operations things going on.
So what?
So how does Enterprise Architecture help enterprise governance, development, and operations? And what is needed here for Enterprise Architecture to succeed in its supportive role? Let’s investigate some possibilities!
Governance comes in many forms including strategic management, portfolio management, project management, etc. The focus being making decisions which brings about an observation – the Enterprise Architecture activity must be geared to help make better decisions. This means the Enterprise Architecture efforts need to result in highly valued enterprise analysis that can support the decisions that need to be made.
So a thought experiment, rather than getting in front of a Board meeting and trying to explain the “Enterprise Architecture” and the method used to maintain it, there needs to be focus on answering questions that are either implicitly or explicitly being asked. So start by putting yourself in a Board seat and ask yourself – what questions do I need answered to make decisions on strategic changes, investments, partnerships, to name a few. Would looking at an Enterprise Architecture model be as useful as getting a report from the Enterprise Architects that says, with a high level of confidence, there are capability gaps that have significant impact in efficiency, or there are significant overlaps in functionality that result in uneven value delivery, or data inconsistency are costing significant overhead? To answer myself – well, not really! Just deliver the information that will help the decision-makers and don’t force models on them. It won’t take too long for the decision-makers to think about the analysis and say we need to invest on filling the capability gaps, reducing the overlaps, and taking care of the data inconsistencies. Then they might even say go out there and help implement the necessary changes!
To provide the above, the Enterprise Architecture must capture what was observed, orient it into a “bigger” picture, put decisions in context, and show where action is needed. The key for this is getting access to the data and having the funding to do the Enterprise Architecting job! So it should be clear that trust must be built between the decision-makers and the Enterprise Architects. So listening to decision-makers, understanding their needs, and providing them answers to questions asked or unasked are part of success. Getting access to data and the funding to do the job is a requirement.
In the development area, it’s not only about information technology! There is employee training, business process re-engineering, lean six sigma, software development, infrastructure maintenance, procurement, etc. And a single motivation, or transformation, will call for a portfolio of developments across these areas.
Again let’s go back to answering questions – when there was a decision to improve customer experience, there are obvious questions such as “what does that entail?” and “what areas of the business are impacted?”. I’m sure you can think of more. This represents a great opportunity for the Enterprise Architect to provide answers to those questions. Another really important question is “how do we ensure that all the developments stay true to the course?”. Answering this question is a great place for the Enterprise Architect to show the guiding principles that will ensure faithful delivery and, as well, to demonstrate how the Enterprise Architect will help apply those principles in any or all developments and/or procurements. Similar questions and answers should be addressed for the topic of people, process, and technology standards!
The developments will ultimately find their way to operations! Changes in people, process, and information technology will be deployed to improve operations – the place where value is created for the core business, or mission, of the enterprise. The most obvious question for the Enterprise Architect to answer … “is it working as planned; for better, or for worse?”. Other questions could be “are the right administrative controls in place to optimize operations for current conditions?” and “what are the operational gaps being observed?”.
The above assumes the Enterprise Architects involved can make a shift from being part of an intellectual authoritarian organization to an empathic support organization. The Enterprise Architect is less focused on telling people what to do, and more involved with listening and answering questions, and helping get it done through light weight guidance. This requires the Enterprise Architect to be the person answering questions, not asking questions. This also requires an Enterprise Architect to be an enterprise analyst, not an enterprise modeler!
I hope this blog has demonstrated that Enterprise Architecture is not a Silver Bullet, but must fit with a myriad of other processes. It is the job of Enterprise Architects to ensure they do the necessary things to make this the right fit by delivering value and being supportive to activities within governance, development, and operations.
@theopengroup
Terence Blevins, a Fellow of The Open Group, is owner of Enterprise Wise LLC and a semi-retired Enterprise Architect. He is currently a Director of The Open Group Governing Board and an active contributor to the Healthcare Forum within The Open Group.
Terry has been involved with the architecture discipline since the 1980s, much of which was done while he was Director of Strategic Architecture at NCR Corporation. Terence has been involved with The Open Group since 1996 when he first was introduced to The Open Group Architecture Forum. He was co-chair of the Architecture Forum and frequent contributor of content to the TOGAF® framework including the Business Scenario Method. Currently he is excited to help the Healthcare Forum work on Boundaryless Healthcare Information Flow.
Terry was Vice President and CIO of The Open Group where he contributed to The Open Group vision of Boundaryless Information Flow™.
He holds undergraduate and Masters degrees in Mathematics from Youngstown State University. He is TOGAF 8 certified.