Home Page Feature IT Staff News

Enterprise Architecture Tool

Written by Sherri Woolard, submitted by Jennie Franke

Enterprise Applications (EA) is kicking off an effort to evaluate and select an Enterprise Architecture Tool to help us more efficiently and effectively respond to the technology demands of WashU.

Summary

Washington University in St. Louis is in the midst of a significant technology modernization journey where the speed and scale of change places huge demands on IT’s ability to be a strategic advisor supporting this change. Following the implementation of Workday HCM/Finance and leading into the Workday Student project, Enterprise Applications possess a wealth of information about our business processes, applications, integrations, data and hardware infrastructure. Arguably, the most written documentation we’ve ever had. This information is largely stored as project documentation for the purpose of supporting development design and quickly becomes stale and fragmented. No matter the project size, EA continuously finds itself conducting a discovery exercise to answer routine IT planning questions.

Capturing this information in an Enterprise Architecture tool will help position Enterprise Applications as a strategic decision support advisor by leveraging an application artifact inventory, dynamic relationship frameworks, cost components, business process and stakeholder information to proactively manage technology life cycles, create transformational roadmaps, understand change impact and support application rationalization decisions.

What is an Enterprise Architecture Tool?

Enterprise architecture tools provide a central repository for analyzing data and metadata about a range of IT and Business artifacts organizations care about, and highlights the impact of change. It captures the dynamic interrelationships and interdependencies within and between an ecosystem of applications, business capabilities, people, processes and technologies. Models represent relationships between these artifacts and are treated as assets that help describe and shape the future of the enterprise. (Gartner – Magic Quadrant for Enterprise Architecture Tools, 2021)

Why Should We Do This?

  • Business-led IT and cloud first strategy is shifting Enterprise Application’s role from a builder of applications to a strategic advisor for integrations, product portfolio management/rationalization, application lifecycle management and future-state roadmap planning. 
  • Reduce EA’s reliance on individual subject matter experts for domain/application understanding. Implementing architecture frameworks and documentation practices that are product focused, dynamic, easily discoverable, consistent and comprehensive could help alleviate SME reliance. 
  • Increase EA’s efficiency in delivering strategic advice services to a wider, decentralized IT organization. No matter the size of the project or question, EA often requires a significant discovery/research effort before we can provide an answer or recommendation. Unknown IT assets and associated costs underpinning an application; no central artifact repository; inconsistent, static architecture reference models with varying degrees of granularity and unknown stakeholders all contribute to project discovery, impact analysis and strategic advising inefficiencies.

How would an Enterprise Architecture Tool fit into our strategic management product portfolio?

An Enterprise Architecture tool would sit adjacent to ServiceNow and Confluence and would provide dynamic, data driven architecture models that show relationships and interdependencies between IT artifacts within the context of business capabilities. Architecture frameworks and iconography combined with a comprehensive database of IT artifacts would render dynamic ecosystem models at different levels of detail in a matter of minutes versus hours. Model and dashboard linkage into Confluence project and product pages will facilitate accurate, robust documentation goals. Strategy, application portfolio management and road mapping capabilities will evolve as the metadata around artifacts matures, relationships/integrations are established and business capabilities are added. Like other applications in this portfolio, it will take planning, effort and time to fully realize value.

Major Risks

  • EA resources needed to enter/maintain data in an Enterprise Architecture tool are over-allocated to other high priority projects.
  • Low organization adoption, inconsistent use will fail to deliver expected value.
  • Implementing a best-of-breed EA tool with a steep learning curve in a low maturity architecture practice could lead to tool abandonment/low adoption.

Current Status

  1. Engage in a 3 month Enterprise Architecture tool product evaluation effort.
  2. Use a requirements-driven approach toward evaluating tool capabilities. Develop use cases which prioritize our current problems and weigh product capabilities against those use cases.
  3. Schedule stakeholder information sessions to solicit/validate use cases, gain insight and buy-in.
  4. Review vendor product offerings, create target list for demos.
  5. Schedule demos with emphasis on our use case examples.
  6. Develop ROM estimate, resources, approach and implementation timeline.
  7. Obtain funding and project approval.

Use Case Examples

The following are examples of the types of things we would expect an Enterprise Architecture tool to efficiently create.

Integration/Relationship Architecture (static drawing took 5+ hours to create by subject matter expert)

Future State Application Strategy

(static Powerpoint – took months to gather and organize by both IT and Business)