The view is out of focus. You can hear a voice say, "Where am I?" The image slowly becomes apparent, and the camera shows a broader angle. The objects around start to take shape, and 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 a strange situation, and it is his/her job is to understand the context, the challenge at hand, and their role in getting out of trouble, winning, or having a "happily ever after."
Every time I participate in an Enterprise Architecture discussion group, this is what comes to my mind: a collective "Where am I?"
Sadly but true, the Enterprise Architect practitioners have not been able to come to terms with 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 tragic 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). So 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, looked 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 I 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 combines 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 fast growth, an organizational design around a critical product, the cumulative result of many years of M&As, 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 correct order.
What may not be available is a complete 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 input and environmental variable, such as regulations, competition, consumer preferences, suppliers, and financial and regulatory environment, 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 critical: "if we outsource function A, what dependencies are there, and what will happen to those dependencies?" An investment opportunity, taking advantage of technology development, a strategic partnership, an M&A opportunity, and the need to reduce expenses, 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 and 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 alternative combinations, and produce pros and cons recommendations. With this information, it can advise the business about risks and possible ways to leverage capabilities, processes, and technologies.
I have found that the approach described above applies to current and future scenarios (business challenges and strategic planning).
Some key benefits of a disciplined approach are that it is predictable and can improve over time. The more times the method is used, the more extensive the knowledge database is available to make recommendations.
Enterprise Architecture can play a crucial role in advising 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. Some Enterprise Architecture departments start under the Technology function, reporting to the CIO, and 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? Many factors 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, and the business seems to be an afterthought. I have attended work groups where hours of discussion are dedicated to qualifying if a concept is aligned and approved for the specific methodology.
2) Focus on the artifacts: the mindset of having the best and more complete diagrams is the most critical 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 create alternatives and solutions together. 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 opportunities, not only for describing the analysis results.
5) Academics and reality: solutions have to be actionable. Academic recommendations and "should" statements usually do not drive results. Without diminishing the value of good academics, the business expects actionable solutions that will transform the organization. Just pointing out that a particular 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, implementing the solution is someone else's job. The Architects have no "skin in the game." They 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 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 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. Still, the business needs to start with a solution that can be implemented and improved over time.
Architects must 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 and the solution and integrate multiple points of view that will make the solution successful in production.
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 my information. You are welcome to agree, disagree, or both.
Enterprise Architects, we must 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 multiple frameworks commonly used by architects, such as TOGAF, Zachman, and others, need a process backbone, so its execution and 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, 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. As a result, we can deliver strategic and operational value. It is up to us to make it happen.
1. Forbes. Bloomberg, Jason, "Is Enterprise Architecture Completely Broken?" July 11, 2014, http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
2. Office Space. Released on February 19, 1999. Director Mike Judge. Production Twentieth Century Fox Film Corporation.