The view is out of focus. You can hear a voice say “Where am I?” The image slowly becomes clear and the camera shows a wider angle. The objects around start to take shape, some clues about the time of the day and the landscape are revealed. Finally, a preliminary assessment of the situation is obvious.
This scene has taken place in many movies and TV shows. The main character is dropped into an unknown situation and his/her job is to understand the context, the challenge at hand and their role to get out of trouble, win or just have a “happily ever after”.
This is what it comes to my mind every time I participate in an Enterprise Architecture discussion group: a collective “Where am I?”
Sadly but true, the Enterprise Architect practitioners have not been able to come to terms on a single description of what we do, how we do it, why and the value proposition.
According to a Forbes article by Jason Bloomberg 1, Enterprise Architects are somehow similar to Milton, the unfortunate character from “Office Space”2 that was laid off and never notified, so he continued to show up to work every day … and made no difference.
In Jason’s article, he notes “… just what an Enterprise Architect is actually supposed to do is curiously still up for debate, more than 25 years after EA’s invention.” A simple Google query of “What is Enterprise Architecture” will give you 20,300,000 results (as of October 21, 2015). We are not short of descriptions.
Just like Jason’s observations, as a young Enterprise Architect working for a Fortune100 company, I had a similar experience: walking into a meeting with business leaders, they sat in silence, look at us and said: “You show me those diagrams again and the meeting is over. We want to talk about our business problems”. Lesson learned, and should add, thanks for one of the best business lessons.
As an Enterprise Architecture practitioner, and a firm believer that every organization has an Enterprise Architecture (some are managed and some are unmanaged), I feel compelled to try to clarify “Where I am”, at the risk of calling for academic debate from my well respected colleagues.
The approach described below is a combination of years as an Enterprise Architecture practitioner, and the valuable lessons I had working closely with the business.
First things first. Every organization has an Enterprise Architecture. It may be the result of a fast growth, an organizational design around a key product, the cumulative result of many years of M&A’s, or just because it was the easiest way to manage the company during the initial years. Regardless of the starting point, every business has a current Architecture. It can be identified, classified and documented.
The knowledge may be stored in the collective mind of all the employees, executives, suppliers and sometimes, customers. The organization works and is operational thanks to all this information about who does what and when. It may not be optimized, but all the pieces are in the right order.
What may not be available is a full map of all the moving parts. A master design that shows how every activity is meant to activate the next step in the value chain. Regardless of the existence of this map, the results are tangible: the organization produces value and generates income.
So, why bother? If companies could control every single input and environmental variables such as regulations, competition, consumer preferences, suppliers, financial and regulatory environment, among others, there would be no need to manage the Enterprise Architecture.
However, organizations often face a challenge that calls for a fundamental change. Then the “what if” scenarios become more important: “if we outsource function A, what dependencies are there and what will happened to those dependencies?” An investment opportunity, take advantage of a technology development, a strategic partnership, M&A opportunity, the need to reduce expenses, just to mention a few situations where an informed decision can represent the difference between long term success and losing business.
And Enterprise Architecture has all the answers? Now we are at the core of the problem. There is no magic ball to ask any question and get “The Answer” Sometimes Enterprise Architecture has been positioned (oversold) as the one-stop shop for all solutions, or even worst, as the only source of answers. This has led to more disillusion and frustration than success.
Enterprise Architecture provides a disciplined approach to business problems to dissect, understand interrelationships, dependencies and constraints. As a result of this analysis, the Enterprise Architecture team can engage the appropriate business owners to evaluate options, test combinations of alternatives and produce recommendations with pros and cons. With this information at hand, it can advise the business about risks and potential ways to leverage capabilities, processes and technologies.
I have found that the approach described above is applicable to both, current scenarios (business challenges) and future scenarios (strategic planning).
Some key benefits of a disciplined approach are that is predictable and can improve over time. The more times the approach is used, the bigger the knowledge database available to make recommendations.
Enterprise Architecture can play a key role to advise the business, along with the other functional areas such as Finance, HR, etc. It is a “team sport”, and requires multiple inputs to ensure a well informed decision.
Is Enterprise Architecture a technology discipline? This is another misconception I have frequently found. The fact that some Enterprise Architecture departments start under the Technology function, reporting to the CIO, are automatically attached and constrained to technology decisions.
Enterprise Architects can use technology to improve the business processes. However, not all the business problems result on technology solutions.
Why so much confusion? There are many factors that come into play when the Architecture discipline is being defined, to my knowledge and assessment:
1) Purism: some Architecture practitioners are concerned with the methodology in its pure form that the business seems to be an afterthought. I have attended work groups where hours of discussion are dedicated to qualify if a concept is aligned and approved for the specific methodology.
2) Focus on the artifacts: mindset of having the best and more complete diagrams is the most important deliverable. Representation of the information is so important that the information itself is never used.
3) Lonely wolf: Architects are meant to use methodologies and artifacts to break down problems and understand their components. Once this is accomplished, the list of required players and subject matter experts should be clear to ENGAGE THEM and together create alternatives and solutions. Yes, with capital letters.
4) Analysis deep, options shallow: after a few weeks or months of analysis, the data should reveal the key components and therefore, the range of available options. I believe Enterprise Architects are accountable for providing options, not only describing the results of the analysis.
5) Academics and reality: solutions have to be actionable. Academic recommendations and “should” statements usually do not drive result. Without diminishing the value of good academics, the business expects actionable solutions that will transform the organization. Just pointing that certain situation “should not happen” or “it is not consistent” with a model, does not help understand what needs to change and how.
6) Someone else’s job: for some Enterprise Architecture practitioners, the implementation of the solution is someone else’s job. The Architects have no “skin on the game”. They just limit their participation to point at the problem, reveal a few alternatives or provide a diagram with the future solution. All of this is of value, but without execution is just a good idea.
Are there any alternatives? Yes, there are many alternatives. Enterprise Architecture delivers real value and can help organizations understand and plan for the future. The degree of success varies by practice and industry. Each company has its own formula. What we at CTI Partners have found to be very effective is:
On the ground Business Experience + Strong Academics = Actionable Solutions
The Architect has to demonstrate experience in operations. Operations provide the knowledge of what it takes to implement a change, mobilize teams and adjust the final solution with both feedback and constraints that may not have been on the design paper.
Having operational experience helps the Architects understand that the “Ideal” or “perfect” solution is great, but the business needs to start with a solution that can be implemented and improve over time.
Architects have to intentionally step into other areas to ensure handshake: information security, business operations, project management, process improvement, etc. The presence of the Architect when those areas are engaged helps build a common view of the problem, the solution and integrate multiple points of views that will make the solution successful in production.
The strong academics are needed to understand the area of knowledge that best fits the challenge at hand: there is no single methodology that can be universally applied. Academics provide the skills to select the right tool for the right problem.
The future. This is one of the oldest questions asked by humanity: what holds the future? I’ll do what everyone who has tried to answer this question has done: I’ll give you my best guess based on the information I have. You are welcome to agree, disagree or both.
Enterprise Architects we have to limit our rhetorical and academic discussions and get closer to the business. Actionable, less-than-perfect and closer-to-operations solutions are needed from us. Some organizations and some practitioners are doing a great job here. Let’s find them and duplicate those processes.
We have to evolve methodologies into processes. The several frameworks commonly used by architects, such as TOGAF, Zachman and others, need a process backbone so its execution, use of artifacts, inputs and outputs are prescriptive. This will provide a repeatable pattern to start, execute and finish. As of today, those great documents and frameworks, can be used almost in any order. This leaves the door open for inconsistency and confusion when executing architecture work. Other frameworks are, or already have successfully integrated processes: Project Management Institute’s PMBok, ITIL, just to mention a few.
Add your thoughts to the list. Enterprise Architects have a unique position in the enterprise that can look across departments, processes and technologies. We can deliver strategic and operational value. It is up to us to make it happen.