Enterprise Architecture and the Road to Enterprise Intelligence

Executives and managers are always looking for ways to increase organizational performance with regard to the effectiveness (How well am I achieving the mission?) and efficiency (Have I optimized my approach to achieving the mission?). In the course of trying to get there they have looked at many different disciplines and approaches including Enterprise Architecture. Enterprise Architecture is an alluring approach because the logic is solid; by understanding the blueprint of the organization from the context of the business architecture, data architecture, etc., you gain a deep understanding of organizational inter-relationships. This will identify the ripple effect of actions, and enable complex analysis thereby unlocking new levels of organizational performance.
Understanding Complex Relationships to Help Deliver Value
Not only should executives be able to use this body of knowledge to support a multitude of decisions, but the execution of the discipline should create a virtuous cycle whereby, better information, leads to better decision making, which leads to better processes and so on. The organization as a whole should become inherently more agile by virtue of its understanding of itself. Unfortunately, for most organizations it has been very hard to close the distance between reality and this vision of the future state. Many organizations have continued to soldier on in search of this promised to-be state because the logic behind the concept is so powerful and the return on investment, if the organization is able to achieve even a hint of the promise, is so great.
The discipline as a whole has been plagued by this reputation of over promising and under delivering almost from its inception. I think that this stems in no small part from the grand scale of the undertaking as it is often envisioned and then methodically trudged towards. Other contributing factors include the dogmatic adherence to specific methodologies and processes as well as a tendency on the part of the practitioners to over emphasize the exercise over the end state. I think this last part, the end state is the where the real disconnect occurs. The problem is that for executives and the managers, the desired end state is a higher performing organization because of the impact of getting the right information, at the right time, to make the right decision.  Unfortunately, the desired end state of the architecture program to often appears to be a complete architecture, adherence to architectural process, the evolution of architectural process and/or the perfection of the PowerPoint presentation. I have no doubt that there is real virtue in the application of many of those concepts and capabilities in order to achieve real and lasting value from your Enterprise Architecture, however I think that it is important to first start by ensuring that your organization is approaching Enterprise Architecture as a means to achieve Enterprise Intelligence.
What is Enterprise Intelligence? Enterprise Intelligence is the decision making capability that enterprise architecture should be leading you to deliver to your stakeholders. Executives, managers and other stakeholders should be able to intelligently query an organizational service that can provide answers to questions that lead to greater efficiency and effectiveness like:
  • Are we efficiently purchasing software/hardware in order to deliver organizational capabilities?
  • How are the services we provide externally and internally performing?
  • How does information flow within the organization?
  • How are the services that we provide supported with regard to resources (IT/HR/Physical Assets)?
Develop Resources that Enable Stakeholders to Improve Performance
Most importantly the questions and answers need to resonate with your organization. It is critical that the outcomes of the processes and activities you perform be things that your stakeholders will use. One of the great failures of many Enterprise Architecture efforts is the failure to make this connection to service provision. It is absolutely critical that your end users be engaged and that your products are used in the decision making process. Otherwise, someone will inevitably come around to question why the effort is being undertaken at all. Nothing, I’ve said above should come as a surprise to anyone who has been engaged in these efforts for any length of time. The temptation to refine the HOW of the EA program is simply too great, and an entire industry of software products, methodologies and consulting services have grown up around it. However ignoring the WHY, is in my opinion, the single greatest cause of the failure of EA to live up to its promise. EA programs need to be run as a service organization to succeed and a major part of that is focusing on the customer experience. The EA team must be in the business of providing UNIQUE insight into the organization, and they must show that they value and are responsive to their customers. That is in large part to say that the value EA provides should be in linking together information in disparate systems within the organization. Tying it to some context provided by the EA organization and making that combined information available to executives and managers in a way that facilitates decision making, prompts further investigation and provides feedback on performance.
Getting from Information to Outcomes Requires Unique Insight
How do you do that? I think understanding the process required to deliver on that promise within a particular organization can only be done by starting from the stakeholders and working backwards in the process for deriving it. I am not saying their is no place for best practice and methodology, but I think an organization is better suited to make a determination on methodology by starting from an evaluation of the decisions it does make (and should make) first. Do not forget the “should” in the last sentence, one of the things that EA as a discipline has gotten better at is in providing examples of reports and artifacts that can be used to support different aspects of the architecture. Some of these are quite useful and one of the real benefits of the extensive promulgation of best practice and methodology-related documentation within the discipline has been the ever increasing number of example reports, dashboards, models and analytic artifacts that are available online. Looking at what others have developed as an end state should help you and your stakeholders identify things that you could use for your own purposes. This is also an area where looking at the various tools on the market can be of assistance as well. Tool vendors often have some unique insight and experience by virtue of working with many programs in a relatively compressed time period, however it should be noted that this can also be a limitation because their job success in large part is predicated on how well they are able to get the software in the door; not on the long term success of the program.  Obviously, real success for these companies comes when their clients succeed, so they will be motivated to position your team to succeed, especially in the run up to the sale.
Without diverting this discussion into an extensive look at EA tooling, I think one of the things that must be recognized is that tooling choices are important because of the way in which they can accelerate the path to value for a program. This will enable the mangement of this complex organizational decision support tool, and enable the type of ongoing analysis and reporting that drives the customer’s experience of EA products. If your tooling is only available to a select stakeholder community you will need to ensure that the value of your teams work makes it into the hands of your customers (executives, managers, etc). If the tooling interface is too complex or if the tool cannot be configured to sustain high data quality, again your stakeholders will suffer.
The tooling should also enable your program to combat another EA program killer, which is stale data. A real Enterprise Intelligence capability requires that the data being analyzed be correct. The user (customer) community will need only find stale data a few times before deciding to get information from other sources. For the architects developing this informational service, it is critical to understand where information comes from, the process that creates it (manual, automated, etc), the refresh requirement in order to maintain accuracy, and the precision/accuracy of the data. This enables the team to provide stakeholders an explicit understanding of the level of confidence they should have in the information they are using to make decisions. One of the issues I often see in the use of EA information to support decision making is the hesitancy of stakeholder to use data to underpin important decisions because the EA team has failed to provide a mechanism for the user community to gain confidence in the information. One thing that programs should do in order to ensure customer trust is to make sure that they have made it easy for stakeholders to develop confidence by providing clear labels, open discussion of informational flows and appropriate messaging during training sessions and service desk calls.
Establish a Clear Line of Site from Inputs to Reporting
Additionally, achieving the benefits of Enterprise Intelligence requires a real focus on strategic communications, training and support. Far too often the focus of an EA effort is on process and content, and while I agree that without these your EA program will certainly fail, these alone are not enough to sustain a program. The stakeholder community cannot leverage any of your good work without an understanding of what information is available, how to access it and an understanding of who to call in order to ensure they get value from it. The point has been made often with regard to the corporate use of big data, analytics, and statistical information that these capabilities often under deliver on their promised return of investment because of a lack of organizational readiness to leverage them. The same is true for Enterprise Architecture. A commitment must be made on behalf of the program to not just develop the information and processes needed to succeed, but to mentor those that are supposed to be receiving value from them and how to get that value. A successful EA program invariably includes someone that is focused on strategic communications and marketing in order to ensure that the organization is aware of the value available from the program. This messaging is further developed and enhanced by ensuring that training is available across the stakeholder spectrum. Too often these types of programs inappropriately skew towards a “Let me tell you about how to do EA” approach. This is not productive for those whose job it is to use EA products to get organizational value. I recommend that one starts the process by understanding the stakeholder community and their individual use cases for EA. Then develop a training curriculum that specifically helps them  get the results they need from EA. Another approach is to stack training in order to meet specific organizational transformation objectives. For example, the success of a particular program may be enhanced by ensuring that training is available to help architects understand how to better use a specific tool that will be used to meet an objective, this may be followed by a workshop to meld training with organization specific content to drive a specific outcome while building skills. This may also be combined with executive brown bags that ensure that the people who need to use the information that is being developed are ready to leverage it for the greater good of the organization when it becomes available. In this way, great training programs not only increase the ability of the organization to achieve performance targets, but they also serve as another outlet for strategic communications.
Remember that Different Stakeholders Need Different Training
Finally, great EA programs make sure they deliver a top notch service experience for their customers including making sure someone is there to pick up the phone and support the user community. When you think about the dollars that have been invested to get the right information, in the hands of the right people, so they can make the right decision it is critical that the program is there to support its customers in getting the best value. So often I find that executives and mangers have essentially opted out of their EA programs because “It’s too hard to get real information” or because “I don’t know where to start.” Even after you have done the training, held your “Lunch and Learns” and provided workshops you still need to be there when your customer needs help. Every support or service request is a critical opportunity for the EA program to shine. I highly recommend that a  single e-mail address for support be used, and have a single phone number for people to call. It goes without saying that this service needs to be RESPONSIVE.  Being a part of a business or mission success is the start of an ongoing relationship that will sustain the EA organization in lean times and ensure that there are vocal champions outside the EA organization. That’s it. This is all you need to succeed in turning your Enterprise Architecture program into an Enterprise Intelligence program, and winning the hearts and minds of your customers.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

Be Sociable, Share!

3 thoughts on “Enterprise Architecture and the Road to Enterprise Intelligence

  1. Pingback: What is Enterprise Intelligence? | Focused on Performance

  2. Pingback: Enterprise Architecture and the Road to Enterprise Intelligence | Focused on Performance | andresthearchitect

  3. Pingback: Enterprise Architecture and the Road to Enterprise Intelligence | Focused on Performance | Richards Innovation Blog

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>