MAKING OF A SUCCESSFUL ENTERPRISE TECHNICAL ARCHITECTURE (ETA)
By: Mehrdad Foroozesh, Ph.D., P.E.
President, Inquest Corporation
During my years at Sprint, we set out to research and identify the key elements that help IT strategies succeed. Our goal was to identify the critical success factors and common mistakes that lead to project budget overruns, delays, and major failures. In conducting our research, we decided to take a holistic approach to developing an ETA. Recognizing that these initiatives encompass organizational change, we began by reviewing the experiential literature and books written by several renowned management consultants on change. Among them were the works of Peter Drucker 1, James C. Collins 2 , Jerry I. Porras 2 , John P. Kotter 3 , Robert W. Jacobs 4 , Michael Hammer 10 and many additional white papers published by the Harvard Business Reviews on Change and on Corporate Performance. We also researched Sprint's NOMAN (Network Operation Management) knowledge base as well as the published experiences and methodologies of several renowned enterprise technical architects, including: Larry DeBoever 6 and John Zachman 5 , who helped pioneer this discipline even before it was called Enterprise Technical Architecture.
IT executives are often caught between a rock and a hard place. They are the interface between the technologically inclined IT staff and the business-minded, line-of-business managers – CEOs, COOs, and board members. Most major IT initiatives require that the status quo on both sides of the house be disturbed. The line-of-business managers and the IT staff must be driven out of their comfort zone. IT executives are used to being forced out of their comfort zones by business managers. Today, with the explosive growth of the Internet and the expansion of e-commerce, IT executives are finding that they themselves have become increasingly more instrumental in helping their enterprise seize new opportunities outside of its traditional comfort zone. IT-driven business initiatives are becoming a common phenomenon in many businesses.
Unfortunately driving people out of their comfort zones or pushing them to the outer edges of their circles of influence can be a formidable challenge. Identifying and discussing crises and major opportunities in order to build a strong sense of urgency is critical when convincing people that business-as-usual is no longer acceptable. Both line-of-business managers and IT staff must understand the importance of dealing with crises and seizing new opportunities.
James Collins and Jerry Porras 2 , through extensive research, discovered that visionary companies tend to put in place processes that constantly drive people out of their comfort zones. For these companies “good enough” never is. More often than not, they use BHAGs (Big Hairy Audacious Goals) to stimulate progress. To do this, IT executives must introduce "mechanisms of discontent" that obliterate complacency and encourage change and improvement from within. Furthermore, IT staff must understand that comfort is not the objective. They must proactively operate outside their comfort zones looking for new opportunities, rather than merely performing day-to-day tasks. When is the urgency rate high enough? John Kotter 3 concluded, "when about 75% of the management is honestly convinced that A business-as-usual is not acceptable." One could also conclude that budget allocations tend to have a direct relationship with this number.
Any ETA initiative must have full support of the CIO, and the business executives who are destined to become stake-holders in the effort. John Kotter 3 refers to this step as “building a strong guiding coalition”. The guiding coalition must have enough power and authority to make change happen. The coalition must take it upon itself to communicate the sense of urgency to the rest of the organization.
It is important to realize that the guiding coalition should expand well beyond the IT organization. After all, how can one attempt to align IT strategies with business goals if business decision-makers and executives are not part of the initiative? Always remember that IT is just one of many elements that form business processes. Our experience shows that IT initiatives that have developed a strong executive sponsorship across the board enjoy better funding than those managed in isolation.
Should the CEO or COO be part of the coalition? Obviously, these individuals have the power to deal with all organizational barriers and could significantly improve the probability of success if included. But the answer really depends on the scope of the initiative. Architecture initiatives that require major expenditures or entail business process reengineering efforts should have full support of the COO and CEO. Here we define reengineering to mean: “the fundamental rethinking and radical redesign of business processes to bring about dramatic improvements in performance. 10 ” Less dramatic architecture initiatives should have at least the full support of the CIO and other executive stakeholders.
In today's complicated and diverse world of technology, success demands teamwork. Managers often forget that "playing on a team" and being a “team player” are two different things. Many times, people that play on a team perform their individual tasks with little or no team interaction. Peter Drucker 1 compares this to a baseball team. "Up at bat, you are totally alone." He goes on to state that teams who strategize and work together can be compared to either a football team, where players have fixed responsibilities but play as a team, or a tennis doubles team, where players have primary roles but cover their teammates. In transforming an IT organization, one should look for football and doubles teams. Baseball simply doesn’t work.
At Sprint, we viewed teamwork as a crucial element of our success and an integral part of our culture. We took steps to foster teamwork through training and teambuilding exercises. Each new consultant spent a week at a secluded retreat with colleagues to strengthen his/her sense of teamwork. This process was repeated every three to four years to further reinforce the Sprint culture. Even though Sprint consultants spent most of their time at client locations, we discovered that teamwork gave them that added confidence that enabled them to excel at their work. They quickly became part of the customer's team yet still relied on the Sprint team to give them that extra support. We saw consultants who lived in distant cities frequently contact each other for guidance. The success of one team member then became the success of the Sprint team as a whole.
Unfortunately, few of our customers devote the time and resources necessary for this kind of employee development with their IT staff. We have seen technical analysts sent off individually to classes that emphasize teamwork in a classroom setting. While this is well intended, we question its effectiveness. When undertaking any major IT initiative, we strongly recommend that the team participants be sent off to a three to five day teambuilding exercise that reinforces teamwork in more than a simple classroom setting. Do not be afraid to put the entire IT organization through a similar exercise in groups of reasonable size. Our first-hand experience shows that this front-end investment in time can shave many weeks off projects. It also improves employee retention.
People who refuse to be team players can be extremely detrimental. IT and business executives should monitor and take quick action to remedy such a situation. The negative consequences of inaction are far more damaging than the inconvenience of dealing with the situation early on.
In developing an Enterprise Technical Architecture, it is critical to assemble a balanced team – one that possesses a deep knowledge of the enterprise as well as the technical skills that are critical to the success of the initiative. This of course demands participation from lines of businesses as well as IT operations and engineering groups. Simply put, all stakeholders must be involved. Since business processes cross many organizational boundaries, the team must also include process oriented individuals who have a thorough understanding of the big picture.
Drucker 1 listed “feeding problems and starving opportunities” as one of the five deadly business sins. Drucker said that, almost without exception, the best performers in most organizations are assigned to take care of problems, leaving the opportunities to fend for themselves. We have discovered that IT organizations are just as guilty – if not more so – in committing this sin. Most talented and experienced IT staff are often busy fighting fires, leaving new strategies to those who may not have the skills to respond in an adequate or timely fashion.
This reminds me of a Fortune 500 company which, in 1995, embarked on an enterprise systems management (ESM) strategy. The goal for the first phase of the project was to automate monitoring and alert notification for all UNIX systems in six months. At the time, their most talented employees, who had designed and deployed their extensive UNIX server farm, were preoccupied with daily management of the servers. Management then decided to assign the ESM project to a team of three – two of which were transitioning from mainframe to client/server technology, and the third, who was a junior UNIX system administrator. This team was charged with the task of identifying the requirements for the ESM solution, product selection, and deployment in a production UNIX environment. Needless to say, not only was the project starved, but the experienced client/server team that had put the UNIX farm together was never invited to seriously participate and quickly lost faith in the initiative. This resulted in continuous time and budget overruns.
Whenever the right skill sets are not available, the organization must admit that a problem exists quickly and take corrective actions. IT executives should be prepared to invest heavily in training their staff. Whenever certification programs are available, encourage or require your staff to participate. However, always remember that years of experience can not be replaced by two weeks of training. In the above example, it would have been better to assign the ESM project to the experienced UNIX team. They would have had a better understanding of the requirements and would have been in a better position to evaluate and deploy the product. At the same time, the less experienced team would have benefited significantly from working the daily tasks. When lacking in-house expertise and experience, augment the project team with outside consultants. You should also consider using contractors to free your talent from the need to fight daily fires.
Let’s not confuse creating a “sense of urgency” with developing a “vision”. The sense of urgency communicates the opportunities or crises – what needs to change, and why it should change. Vision communicates where the organization is heading and how it is going to get there. "Without a sensible vision, a transformation effort can easily dissolve into a list of confusing and incompatible projects that can take the organization in the wrong direction or nowhere at all," wrote Kotter 3 . In developing a vision for the ETA initiative, the architecture team should focus on the enterprise business drivers. This information could come from business managers, executive reports, and quarterly or annual reports.
Collins and Porras 2,8 , based on their study of visionary companies, developed a vision framework that consists of two components: the "core ideology" and the "envisioned future." The core ideology is further decomposed into "core values" and "core purpose," both of which should be long lasting statements. The "envisioned future," Collins and Porras noted, should consist of a Big Hairy Audacious Goal (BHAG) and vivid descriptions of what it would be like to achieve this goal.
In applying their principles to Enterprise Technical Architecture, we believe that the IT organization should establish a core ideology that fosters clock building vs. time telling. All IT initiatives, including ETA, should share the same common core ideology, which should also be consistent with that of the enterprise. On the other hand, the envisioned future could change over time as business drivers change. The architecture team, as well as other IT and business teams, should form their own BHAGs relating to current business drivers and should clearly articulate their vision to the rest of the organization. And finally, the guiding coalition must agree with the vision. In fact, they must be active participants in its development.
Jeanie D. Duck 7 stated, “...management is the message. Everything managers say – or don't say – delivers a message.” The faith of most IT initiatives is in the hands of management and more importantly the guiding coalition. Every meeting, every appointment, every schedule that they hold can either send a clear message or start rumors. It all depends on how openly management chooses to communicate its vision and its sense of urgency. The guiding coalition and the architecture team should communicate all things that should be done differently. They must use every vehicle possible to communicate, including setting examples by leadership. Don't assume that by choosing silence you are not communicating – gossip fills the vacuum quickly. Usually the rumors are worse and more negative than anything that is actually going on.
“In any organization where information is power and access to information is determined by who attends certain meetings, a task-force identifies who does and doesn't have power,” noted Duck 7 . The message you do not want to convey to your IT organization is that your architecture team is an elite group in control of everyone else's future. “When the task-force members put off communicating with the rest of the organization, they prevent people from understanding the design principles that guided them, the lessons they learned from previous experience, the trade-offs they had to make. They unwittingly prevent the people who are expected to implement the change from participating or buying in...,” wrote Duck.
The architecture team should quickly publish the minutes of every meeting and hold open-door meetings whenever it is possible. Secrets serve no purpose whatsoever, not even when the team is considering outsourcing. And one should always be sensitive to people's feelings. Discussing the impact of the vision on people's positions, career paths, and their future with the company is an important part of the communication process.
The guiding coalition must be willing to get rid of obstacles to change. It must also stimulate progress by encouraging risk taking and nontraditional ideas. Architecture team members and other IT staff must be empowered to consider non-traditional ways of achieving their goals. In doing so, IT executives must understand that increasing their staff’s circle of influence needs to be done in a responsible manner. Giving a technical analyst responsibility for a million-dollar project may not be a good idea if the analyst has never managed a budget. Prepare your staff for the added responsibilities first. Otherwise, you may be setting them up for failure.
And on the subject of failures, Collins and Porras observed that visionary companies tend to tolerate failures and risk taking more than others. These companies tend to implement processes whereby they try many ideas, keep what works and discard what doesn't. It all starts by empowering their staff to think outside the box. Of course failures can quickly become a costly proposition. That is why taking small steps and going for short-term wins may not be a bad idea.
Although Enterprise Technical Architecture is about continuous realignment with business goals, each phase of the process must be treated as a project with an end in sight. Taking small steps and creating short-term wins is an important part of a wining strategy. Collins and Porras pointed out that "small incremental steps can form the basis of a significant strategic shift." They added that, "If you want to create a major strategic shift in a company, you might try to become an incremental revolutionary and harness the power of small, visible successes to influence the overall... strategy." Our own experience at client sites confirm this theory.
Incremental successes (three to six months in duration) are powerful tools for keeping people motivated and dedicated to the cause. It further reaffirms the guiding coalition's vision and helps win even more consensus throughout the organization. Needless to say, it is also easier to tolerate small, incremental failures than massive, expensive ones. A small failure gives you the opportunity to solve the problem, change strategy, experiment, or try something new – a luxury that you won't have when you are three years into a project and four, ten or twenty million dollars over budget.
Consider an Enterprise Systems Management (ESM) or an Enterprise Resource Planning (ERP) initiative. When implementing ESM solutions such as Tivoli or Unicenter or an ERP solution such as SAP R/3, it is always best to take small and calculated steps. Do not jump into a gigantic project headfirst. Experiment with pilot projects for each module to see if they meet your requirements. Identify technical and organizational barriers, and create short-term wins. Repeat the process for additional features. And while experimenting, develop the certified expertise that you need to take the next steps.
While creating three to six month short-term wins, remember that ultimately you must show value to the organization. It is commonly believed that architecture initiatives should begin to show value within12 months. To clarify this point, consider our ESM example. While deploying the solution successfully is a short-term win, it may not add value until it is effectively utilized by the organization.
Any Enterprise Technical Architecture initiative must be managed as a process utilizing a framework and a methodology to collectively organize the objectives and the means to the end. The purpose of a framework is to identify all the areas of concern. A methodology on the other hand, helps you develop a consistent approach in addressing all the issues related to those areas identified by the framework.
When using a framework, it is less likely that areas of concern will be ignored. A framework can help you develop a clear picture of all the things that you must consider before you embark on the initiative. This could result in significant savings in time by eliminating surprises that might impair the project. Our experience at Sprint showed that by using the NOMAN Framework, Sprint's consultants could predictably deliver significantly improved results – making the outcome of their projects more deterministic and less probabilistic.
In addition to Sprint's NOMAN Framework, there are many other relevant frameworks in existence. Most noteworthy is the Zachman Framework5 named after its founder John Zachman. The Project Management Institute's PMBOK (Project Management Body of Knowledge) also defines an extensive framework for project management. Regardless of which framework you choose to use, you will quickly discover that understanding the maze before you enter is an invaluable advantage when it comes to finding your way out.
On the subject of methodologies - many companies and consulting organizations have adapted their own variation of project management methodologies. The concept of gate reviews appears to be popular with many. However, in addition to using a project management methodology, it is important to adapt a superceding methodology that addresses the entire architecture lifecycle from assessment, to strategy setting, to implementation, and on to operation and process optimization.