Partnering, Procurement and Persuasion

Hello again,

My colleagues and I just returned from the Educause Midwest Regional Conference where we presented some of our progress in the last year of our Enterprise Architecture program. The presentation is entitled, "Enterprise Architecture: Partnering, Procurement, and Persuasion" and the slide deck can be found be clicking here.

In the early stages of the Enterprise Architecture program at SLU, we've had to use the tools available to us to make a difference. As Jim Phelps pointed out in his presentation, this is fairly typical of EA in higher education - flexing and adapting the practice of EA to achieve the goals of a unified architecture program.

At SLU, we've partnered with the ITS Business Office in support of the IT procurement process. We've helped clarify standards and we've helped analyze out of the ordinary procurement requests. We fostered an RFI and RFP process which has led to a change in procurement practices for servers and storage. Outcomes of this effort have included implementation of a Unified Core Computing environment and about $2 Million in savings for SLU. We've weighed in on various architectural and standards issues, helping persuade decision makers and developers to support the "to be" architecture suggested by strategy. It has been a heck of a year.

Nonetheless we have a long way to go. Management support of architectural governance and access to strategic planning opportunities continue to be challenges. The first issue has a lot to do with organizational maturity. TOGAF has a lot to say about architectural maturity, wherein I think we probably exist at Level 1.

Level 1: Initial

Informal IT architecture process underway.

1. Processes are ad hoc and localized. Some IT architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
2. IT architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
3. Minimal, or implicit linkage to business strategies or business drivers.
4. Limited management team awareness or involvement in the architecture process.
5. Limited operating unit acceptance of the IT architecture process.
6. The latest version of the operating unit's IT architecture documentation is on the web. Little communication exists about the IT architecture process and possible process improvements.
7. IT security considerations are ad hoc and localized.
8. No explicit governance of architectural standards.
9. Little or no involvement of strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.

I also found an interesting extended maturity scale that describes negative levels of maturity. Scary to think in some ways and in specific instances we may be below zero in our architectural maturity.

Brenda Michelson gives some excellent clues for success in her blog, elemental links. Here's an excerpt:

Keys for Success

No doubt, individuals in enterprise architect positions are extremely self motivated, and in their minds, success is never in question. However, there are things CIOs can do to ensure their enterprise architect (and architecture) are successful. Here are seven actions you can take:

• Make Room at the Table for Architecture Leadership. The architecture leader must have a seat at the CIO’s table in IT leadership and business leadership settings. The architecture leader, particularly one with an architecture background, will listen and contribute to the discussions with an enterprise architecture perspective. Don’t filter his/her information through a leader with a non-architecture focus.

• Set Shared Goals for Your Architecture, Project and Portfolio Leaders. Reduce the natural tension between architecture, projects, and portfolios, by setting some shared goals related to initial productivity, asset utilization (re-use), and enhancement productivity.

• Fund and Resource the Architecture Team, Early. To realize the architecture, the architecture team must have development and engineering resources. Set this team in motion ahead of the dependent projects.

• Transition the Architecture Assets to Operations. As the architecture portfolio is built out and incorporated into projects, transition the day-to-day operations of the resulting tools and infrastructure to operations teams. Don’t lose your architecture team to operational tasks.

• Integrate Enterprise Architects and Project Teams. Reduce the natural tension between enterprise architects and project teams by having them collaborate on projects. Seed enterprise architects into your project teams, particularly in pilot situations. Loan talented developers and engineers to the architecture team, to build out the architecture.

• Sponsor an Architect’s Forum. Bring all of your IT architecture talent (enterprise, domain, technology) together periodically to exchange ideas, discuss challenges, and tackle your toughest problems. Leverage their collective brain power. Create a community.

• Encourage Enterprise Architects to “Feed Their Brains.” For enterprise architects to stay on top of their game, they need to continuously explore, stretch their boundaries, and sometimes, just sit and think. Recognize this is part of the deal. Be patient when the areas they explore don’t have an obvious connection to your business or technology plans. Trust their instincts.

***

Good goals, don't you think?