Jumpstart or Re-boot your Enterprise Architecture Program

jump!

There is a consensus that technology will play a large role in an organization’s success in the coming years. Technology has seeped into almost every aspect of the organizational value chain and, in many cases, directly supports competitive advantage. From the manufacturing floor, to planning, to marketing, to finance, every aspect of the organization is touched by technology in a way that is quite different than it was just a few years ago. Moore’s law, and the inevitable gains in processing power, is a tangible benchmark that can easily be measured, but innovation and the network of ideas, people, and technology that have arisen in the past 30 years have made an organization’s ability to benefit by leveraging technology to the benefit of the organization a critical differentiator. Underneath all of the much-hyped methods whether it is a shift in computing to the cloud or using enterprise architecture to increase the efficiency and effectiveness of leveraging technology, executives need to buy in, clearly communicate the value they intend to gain, and focus on execution to realize that value. In this article, I will focus on starting or rebooting an enterprise architecture effort, which has been touted by many as the means to align technology with business and ensure the realization of value from technology investments. Unfortunately, many of these efforts have failed to produce the returns that were promised.  In the following entry I will detail how to avoid common pitfalls and make your EA a success.

Building a successful EA program requires organizational credibility and that is why executives charged with developing an EA program should first think of their program as a project. This pulls the focus of the program in closer. Looking more than a year into the future is too long, I know this sounds drastic because EA folks are supposed to be more strategic than tactical, but I think most efforts fail to deliver strategic value fail because they don’t have any of the organizational credibility that is developed by delivering a measurable return on investment in the near term. I want to stress that this isn’t a recipe for every organization; this advice is targeted at those that are trying to start a program or reboot one that hasn’t been delivering. Every program needs to find a path to credibility in order to deliver value in the long term. Using the project approach allows you to become credible now so that you are seen as a responsible steward later. This solves the chicken and egg problem facing so many organizations when it comes to EA because the program needs buy in before it can show results.  Taking a project-oriented approach that delivers value over the course of a year gives proves to the organization that you can deliver results. A program-oriented approach subtly changes the focus of the effort to building the organization and the expanding role of the transformation rather than forcing the focus to stay squarely on delivering initial value. Stay focused on near term value.  Once the concept is proven and a return on investment is shown many of the things that are often discussed, as critical to an EA programs success, such as executive buy in will no longer be a problem because the numbers will be there to support it.

So if you treat your EA program like a project – where should you start? For an EA program I think near term success requires a laser like focus on three key things:
•Problem Definition & Scoping
•Skill Development and Problem Solving
•Executing on the Path to Value

Problem Definition & Scoping

Lack of scope is one thing that destroys the value of an EA program.  Enterprise architecture means the whole enterprise, but most EA programs either end up with a mile wide EA that is an inch thick or pockets of detail that don’t provide enterprise value. Sometimes the dogmatic adherence to a particular methodology derails the path to value because the enterprise architects are working from someone else’s recipe for EA success. I believe that an EA should identify an enterprise problem and help solve it as a project, which will help develop credibility and if done correctly, should provide a pillar on which the greater success of the EA program can be built. Critical factors to consider are the probability of success, access to information, and potential value to the organization. Do NOT forget the probability of success; great intentions and great potential won’t get you anywhere unless you can pull off the win. You absolutely must be able to develop a problem statement that will be universally accepted and that will define what success looks like. You can take on harder to measure, more strategic problems next year. A first great project starts with your organization’s application portfolio, unless your organization already has a good handle on it.  This is an ideal place to start because it is an area in which an EA team can bring exceptional short-term value while building a resource for the organization that will provide long-term value while building a resource for the organization that will also provide long-term value. Done correctly this should help you develop a high level understanding of the capabilities required to execute the business of the organization, a complete application list in the context of those capabilities, and an understanding of the technology components that comprise the applications. In most organizations I’ve seen the results of this analysis is fairly stunning, since redundancy and opportunities for consolidation become almost immediately apparent.

Skill Development and Problem Solving

Once you have defined your challenge, you will need to make sure you have the appropriate skills in order to accomplish the tasking. Even in the application portfolio example discussed above, you often need to develop specific skills with regard to tooling and taxonomies. Scoping down the work required to develop a full blown EA program into a specific effort to develop organizational value may also bring into focus the need for critical training around specific areas of effort that may dictate project success. However, if you want to fold these informational inputs into a larger EA framework you will need to begin closing any skills gap your team has with regard to understanding the bigger picture of what EA can and should be delivering. Most EAs come from solution architect, or other more specific architectural or technology oriented disciplines. Training on big picture EA concepts as well as meeting specific skill gaps, is critical during the execution of the project phase so that your project oriented EA effort doesn’t become another stove-piped information set. Even though you will have scoped your effort as a project it is critical to keep in mind that this is a step towards solving larger and more strategic issues facing the organization. Training around EA concepts and other more general skill sets is critical in order to keep the big picture in mind as you work to solve a more narrowly scoped organizational issue.

Finally, you may also want to address general productivity and problem solving. Is your team able to deal with communication challenges, leadership issues, and collaboration or organizational productivity concerns? Figuring out how to work together effectively can be as big a challenge as figuring out how to solve a particular problem. I find that EA teams that are broken down by EA functions like security architecture, information architecture, and business architecture can sometimes become their own stovepipes. Using a project-based approach solves the stovepipe issue because it forces staff to work together to develop organizational value. Too often EA programs that are focused on building a program have individual architects working to build “their” architecture rather than a shared architecture that is understood across all domains. If your team is struggling to work together, consider addressing productivity, teamwork and collaboration skills specifically outside of the technical skills required to implement the EA project. Sometimes the type of detail oriented, high intelligence individuals who are able to understand and develop EA concepts require help in the area of soft skills.  I cannot stress enough how important this area will be to creating real organizational value. Enterprise architecture will always involve relationship-building skills in order to be successful because you are dependent on others to gather and use information. Don’t become so focused on technical development that you lose track of the soft skills required to solve real organizational problems.

Executing on the Path to Value

Once you’ve identified a manageable scope, sold the idea to management, developed success metrics and identified skill gaps it is time to execute. During execution, it is very important to stay on schedule and ensure that your project does not become a victim of scope creep. Many of the inputs into even something as simple as the application portfolio effort mentioned above can easily become the victim of a lack of access to outside resources. A critical factor in meeting your goals is staying on top of the execution and schedule and leveraging your executives in order to get the information you need to be successful.  Make a project plan. You cannot manage your EA program like a project without identifying key milestones and marrying them to a realistic timeline. Keeping a tight rein on that timeline and ensuring that you manage the effort in order to meet these evaluation gates is critical. If you begin to fall behind or encounter organizational roadblocks or unanticipated challenges it is imperative that you react in real time. EA programs are often derailed by the combination of scope creep and a perceived lack of value. If you begin to slip on schedule ask yourself why. The answer is almost always a skill gap, scope creep or lack of access to informational resources. The latter is probably the hardest to deal with but if you have defined the project well and scoped it with an eye towards organizational value you should be able to make the case to an executive who will help support your access to other organizational resources. If you find yourself with a skills gap or scope creep, you may want to consider leveraging outside resources to bootstrap yourself into your initial success. Having a seasoned EA or tools specialist that can help address technical issues can be critical to the success of the effort at large.  Having outside support can also help guard against scope creep by enabling a respected outsider to weigh in on the implications of specific items that may fall outside of scope and, therefore, either increase the time to value or add little value.

In fact if you are rebooting or starting an effort from scratch it is very likely that you will need some level of outside assistance in order to meet your requirements. The type of assistance is likely going to be dictated by the skills gaps you have previously identified, and most new teams will require some type of outside assistance as they execute. Areas to think about in advance are tooling, general EA competency, productivity and mentoring. I think the first few are self-explanatory but I would like to expand on the idea of mentorship and introduce the idea and importance that workshops can have on enabling real results. I am a big believer in training and many of our folks hold multiple certifications in addition to advanced degrees. However too often this training is under utilized because of the gap between learning new skills and using those skills. Mentoring can help bridge that gap as well as provide the type of expert advice and experience that will prevent costly missteps and ensure that you meet your success criteria. The right mentor may also enable you to better communicate value upstream by virtue of their ability to communicate current efforts in the context of their own experiences. Having someone who has lived the project you are now executing keeps missteps to a minimum and ensures the path to value is fairly straight. Workshops are another great way of leveraging the experience of experts in the context of your own projects. In our application portfolio example it may be useful to run a workshop around the evaluation of a application portfolio that provides both training value in terms of developing an understanding of how to evaluate the portfolio as well as real value by performing those very tasks using your organizations real data. I believe this type of combined learning is invaluable in terms of building near term value and long-term skill development.

Conclusion

Your ability to jumpstart or re-boot your EA program depends on defining project level objectives, building the right skills, and staying on top of execution. The eventual goal of most EA programs is to truly transform the organization in order to support agility, efficiency, and effectiveness in a manner that delivers a sustainable competitive advantage by achieving a more perfect relationship between technology and the business. It is by its very nature a complex and difficult endeavor. In fact most organizations have been unable to get to the value they hoped for from these types of programs and projects. The fact that so many organizations continue to support these efforts is a testament to the benefit the organization will achieve if it is successful. Executives intuitively understand how beneficial this type of program could be, but, they often lack a proven means to achieve this value. I suggest focusing on scoping a project level EA first because it removes some of the complexity from the program and defines it in manner that can be understood by the business. In the application portfolio example, the business case is centered on removing cost and increasing efficiency in the application portfolio. Once complete this EA project will have developed a very strong informational backbone on which you can hang other program level EA inputs, provided a return on investment back to the business and established organizational credibility. This is the foundation on which other more strategic efforts that may have harder to measure outcomes can be placed. I believe that even EA programs that have a history of success should always evaluate their program portfolio to ensure that there is a mix of projects that deliver short and long term value in order to ensure that they stay relevant to the organization as a whole. Your EA program should never have to hunt for organizational or executive buy-in. If it is done correctly it should become a driving force within the organization that ensures the efficient and effective application of technology in order to improve performance. Getting there will require your team grow their skills, keep their focus and build relationships across the organization.

Put our team to work improving your organization’s performance.
Visit Millsapps, Ballinger & Associates online.

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!

One thought on “Jumpstart or Re-boot your Enterprise Architecture Program

  1. Pingback: Top 6 Reasons to attend the Troux Worldwide Conference | Focused on Performance

Leave a Reply

Your email address will not be published.