4 Best Practices for Deploying Enterprise Architecture
The best way to think about enterprise architecture is to view it as all the common-sense measures IT managers would make if only they weren't challenged by the realities of our "deliver something now – and do it cheaply" culture.
Yet because we all work in a much different environment today than even a decade ago, developing an enterprise architecture has become more important than ever.
When we started our EA program at the University of Michigan at Ann Arbor, we contracted a consulting firm for an initial IT assessment. They identified 72 unique IT organizations on campus and found that the university delivered 2,500 IT services, but 85 percent were not shared outside of a specific college or department.
There was simply too much redundancy, and it was unfortunate. There were all these really great business processes being used at the colleges, but they were mostly silos – they weren't being rolled out to any of the other colleges or departments. IT teams were reinventing wheels that had already been invented somewhere else on campus, and new, innovative ways to solve problems weren't getting exposure to other organizations. The university decided to develop an enterprise architecture to harmonize UM systems and processes, to eliminate redundancies where possible and to help spread innovative solutions.
During the process, the team discovered that there weren't really a lot of good collegiate EA models or case studies to follow, so we were forced to blaze our own trail and create a new enterprise architecture model. What follows are four best practices from our experience developing an enterprise architecture at the University of Michigan.
Sell the concept across campus. An enterprise architecture is not a readily understood concept outside of IT circles, so it's necessary to sell it aggressively.
Start by launching an awareness campaign. Seek out those executives in the departments and colleges who understand the value of improving the systems infrastructure across the university. They can then champion the enterprise architecture concept to the masses.
Put together a road show, complete with PowerPoint slides and multimedia, and take it across campus, preferably with at least one solid case study from one of the colleges. (At UM–Ann Arbor, we used the School of Public Health to help explain the EA program's benefits.) Get in front of as many committees as possible to help spread the word.
Develop a big-picture strategy. Following the first road show, work with stakeholders to map out a vision for where the university wants to go.
Instead of having multiple cloud strategies, for example, argue for a universitywide strategy that includes a series of services. That way, the institution can negotiate a volume discount with a leading cloud provider.
Become an idea broker. Compile a database of ideas that can be reused by other colleges and departments, and spread those ideas across campus. We have found that people want to share best practices across departments, but they often don't know that someone else is working on (or has already solved) their problem.
This really addresses two issues. First, it eliminates folks reinventing the wheel every time they need a new program or system. If one college has an efficient way to process undergraduate applications, then there's no reason to have multiple ways to process paper.
EA Benefits: A Snapshot
- Links IT to the organization's mission
- Improves interoperability and integration
- Enables agility
- Reduces costs
- Improves security
- Reduces technical risk
Second, the university can take advantage of standardization. Digital signs are a good example. If one college uses touch screens for students to find maps to classes, but another doesn't, students become confused and wind up having to learn multiple systems to find what is essentially the same information.
Keeping ideas, processes and software applications that work well in a common database saves money and creates standardization across campus that will make the user experience with technology more predictable.
Recognize the cultural barriers that lay ahead. It's really important to understand that developing an enterprise architecture is counterintuitive to how large institutions have operated for decades.
At Michigan we are very decentralized and believe that decentralization is a major factor in the quality of our schools. For example, the medical school is charged with being the best medical school it can be; it is not charged with helping the engineering school be great.
The way to break through this thinking is by explaining the end-user, management and economic benefits that each school will reap – people have to see the value of EA in their domain, not just because it helps IT alignment across the campus as a whole.
Essentially, to encourage widespread adoption of an enterprise architecture requires appealing to people's common sense. After all, most everyone can understand that it's not a good investment strategy to maintain 20 solutions for the same business process if two or three (or even one) will suffice. Consolidation would save money, add efficiencies and deliver a better experience for the user. There's no hard sell in that.
Beyond EA
Once an organization has established an enterprise architecture, it's just the beginning of a entirely new management process.
The federal government, for instance, has created a three-phase approach to integrating systems and programs. EA is phase one.
- The enterprise architecture establishes a comprehensive understanding of core business processes and defines the technology that supports and optimizes them.
- The investment management process (IMP) is a fluid, dynamic method for selecting and monitoring both proposed and ongoing IT investments throughout systems' lifecycles. The IMP has three phases: select, control and evaluate.
- The system development lifecycle (SDLC) provides guidelines and procedures for IT acquisition, development, implementation and deployment, and project management.
To be most effective, these enterprise processes need to have multiple touch points with one another. For example, IMP activities include portfolio management to prioritize and control IT initiatives. But portfolio management highly influences and is in turn influenced by the target EA's business, application, data and technical dimensions.
As an organization develops and rolls out new initiatives, those initiatives need to mesh with the predetermined SDLC, which specifies project management and technical activities.
The SDLC also should have touch points with the EA to ensure that an initiative's evolving requirements, design and technology continue to adhere to the target EA. And the SDLC has integration points to areas in the IMP, such as project status reports and risk management.
– Christopher B. Emery, IT policy and compliance director in the Homeland Security Department's Enterprise Business Management Office