I think there is a general consensus that technology will play a large role in how successful most organizations will be in the years to come. 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 even a few years ago. Moore’s law and the inevitable gains in processing power is the tangible benchmark that can easily be measured but innovation and the network of ideas, people and technology that has arisen in the past 30 years has made the ability to leverage technology to the benefit of the organization a critical differentiator for any organization. Underneath all of the much-hyped methods whether it is a shift in computing to the cloud or leveraging 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 be focused on rebooting or starting an enterprise architecture effort, which has been touted by many as the means to align technology with the business and ensure the realization of value from technology investments. Unfortunately, many of these efforts have failed to produce the returns that were promised.
Building a successful EA program requires organizational credibility and that’s why I think most executives charged with developing an EA program would be well served to think of their program as a project first. This pulls the focus of the program in closer. Anything more than a year into the future is too long, I know this sounds drastic and that 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 everyone; 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. Use the project approach 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. Enterprise architecture programs want buy in without earning it first. Taking a project-oriented approach that delivers value over the course of a year gives the organization a good feeling that you can deliver results. A program-oriented approach subtly changes the focus of the effort to organization building and the expansion of the 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 being so critical to an EA programs flourishing like executive buy in will no longer be a problem because the numbers will be there to support it.
So if you should 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
One of the things most responsible for the destruction of value in EA efforts is the lack of an appropriate scope. Sure enterprise architecture means the whole enterprise but most EA programs 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 EAs 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 one of the pillar on which the greater success of the EA program can be built in the future. Critical factors to be considered 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 where you can define what success will look like. You can take on harder to measure, more strategic problems next year. Unless your organization already has a good handle on its application portfolio I would suggest this as a place to start because it is a place where an EA team can bring exceptional value while building a resource for the organization that will 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 will be fairly stunning, as redundancy and opportunities for consolidation will become apparent almost immediately.
Skill Development and Problem Solving
Once you have defined your challenge most organizations will need to close a skill gap in order to accomplish the tasking. Even in the application portfolio example discussed above you will often need to develop specific skills with regard to tooling, taxonomies. Scoping down some of the work required to develop a full blown enterprise architecture program into a specific effort meant to develop organizational value may also really 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 came 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 I advocate for 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 can be critical to keep the big picture in mind even 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, 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 architect, information architect, and business architect can sometimes become their own stove pipes. Another benefit of the project-based approach to developing an EA program is 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 architectural domains. If your team is struggling to work together as a team consider addressing productivity, team work and collaboration skills specifically outside of the technical skills required to implement an EA project. Sometimes the type of detail oriented, high intelligence individuals who are able to understand and develop EA concepts require more help in the area of soft skills than in the more technical areas of the discipline. I cannot stress enough how important this area will be to creating real organizational value. EA will always involve relationship building skills in order to be successful because you are dependent on others to facilitate information gathering and re-use of the information once its gathered. 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. Here I think it is very important to ensure that your project does not become a victim of scope creep and that you stay on top of the schedule. 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. Staying on top of the execution and schedule and leveraging your executives in order to get the informational inputs you need to be successful is a critical factor in meeting your goals. Make a project plan. You cannot manage your EA program like a project without identifying key milestones and marrying these 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 too often derailed by the combination of scope creep and the perception of a 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 last one is probably the hardest to deal with but if you have defined the project well and scoped it with an eye to organizational value you should be able to make the case to an executive to help support your access to other organizational resources. If you find yourself with a skills gap or scope creep it 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 a critical to the success of the effort at large, however 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 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 in someway dictated by the skills gaps you have previously identified, but 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 against 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 understand intuitively how beneficial this type of program could be, they often just lack for a proven means of achieving 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 above the business case is around 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 near 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.
[…] JUMPSTART OR RE-BOOT YOUR ENTERPRISE ARCHITECTURE PROGRAM […]
[…] JUMPSTART OR RE-BOOT YOUR ENTERPRISE ARCHITECTURE PROGRAM […]