Organizations can go either way, and each has its pros and cons. As an Enterprise Architecture leader for over ten years, and now as an Enterprise Architect with SAP, I have seen different approaches, and my perspective has changed over time.
Launching an EA Practice, Keeping an Eye on ROI
When I started my first role as an enterprise architect, the practice in my organization was brand new. While the CIO understood the value of EA, we had to keep our eyes on ROI.
The organization had little documentation on its IT landscape, and none of it was up to date. When anyone needed the details to support planning or troubleshooting, you had to find one of the few people who had it all in their mind and get them to share it. The leadership team did strategic planning in PowerPoint, which didn’t facilitate transparency and reuse.
Building out an EA repository was one of the first things I took on so we could start to understand our current state landscape. Buying a tool was considered, but we decided to apply some “sweat equity” and build it ourselves. Using TOGAF as a framework, I created the EA repository using Sharepoint, Excel, and Visio. Working with our matrixed EA team, it took over one-and-a-half years of sustained, part-time effort to complete the high-priority components.
The EA repository proved to be a critical tool for the EA team, giving us the essential details to support EA analysis for application rationalization and strategic roadmap planning. During organizational transitions such as M&A, the repository provided the required transparency of the organization’s IT assets. Finally, the repository became a valuable resource for onboarding new IT team members and consulting partners on the organization’s IT landscape.
All in all, we were delighted with the results and even shared our experience at SAP’s Sapphire conference: Simple and Effective Enterprise Architecture with Tools you Already Own.Approach #1: Challenges of Building an EA Tool
As happy as we were with the outcome, some problems immediately showed themselves.
1. The EA Repository was outdated as soon as we created it.
At least once a week, we introduced changes into our environment through deployments, configuration changes, and project builds. We did require updates for changes presented to our Change Advisory Board (CAB), but that didn’t catch everything, and compliance with this process was an uphill battle.
We automated a few things, so manual updates weren’t always necessary, but those feeds often broke, and sometimes it took something wrong for us to notice.
2. User Interface affects adoption.
Most of the interaction with our EA repository was through Sharepoint circa 2013. While the modern Sharepoint user interface is an improvement, using the list capabilities to manage hundreds of applications with views and filtering is cumbersome and challenging even for the most technical team members.
As a result, only a few people accessed the valuable information housed in the repository. And getting anyone to update it beyond the core team was next to impossible.
3. Visualizations are valuable, but they take a lot of time to create and maintain.
While we had a process to update our repository that included some automated pieces, the process of creating visualizations of the information was cumbersome. Only the team members with advanced Visio skills could leverage the data in the repository to create visualizations. The result was skilled technical team members using their highly constrained time to create Visio diagrams.
Our overall system landscape diagram showing all applications and their connections at a high level was only updated once a year – a perpetual summer intern project.
4. Relationships created in diagrams aren’t reusable.
Due to the linear nature of the solution, we hit a wall with how to depict more complicated relationships. That led us to reflect multilevel relationships in diagrams. While that provided a short-term solution, each visualization was a “one-off,” and relationships established in them only existed in each diagram itself. An example would be an application server supporting a specific business capability. While we could create those relationships on a diagram, the information about that relationship could not be leveraged again. This meant that the work to document relationships between different elements was done repeatedly. It also meant that diagrams depicting the same relationships sometimes showed them inconsistently.
Approach #2: Buying the Right EA tool
In the years since building that EA tool, I’ve met many enterprise architecture leaders and the topic of tools often comes up. I’ve heard stories of great implementations as well as several accounts of failures. It is clear to me that the challenges faced by enterprise architecture teams around tooling are the same no matter the industry.
Out of all these conversations, a different approach has been suggested:
What if you started with an EA tool before your EA practice was up and running?
For example, as you are forming your team, you could select an easy-to-implement, full-featured tool and use the work of populating that tool to guide your EA team in their understanding of the existing environment. As you progress, you could then sell the value of the team using compelling insights presented through powerful visualizations. Among the other benefits, taking this approach will establish the EA team as a collaborative, efficient, and professional group.
For this approach, it’s crucial that the tool provides a way to quickly generate insights based on your organization’s enterprise architecture landscape. It's also important that the tool be easy to use for all stakeholders.
Here’s a list of things to look for when choosing such an EA tool:
- A crowdsourcing model allowing for information gathering from outside the EA team.
- An easy-to-navigate portal with dashboards configurable for each role in order to increase adoption of the tool and usage of the information it contains.
- An easy-to-learn user interface with built-in data-quality measurements.
- Data-driven visualizations that are automatically created.
- The ability to store multi-level, complex relationships between all data objects.
I believe this approach – introducing a modern EA tool early in the development of an enterprise architecture function – can have a significant, positive effect on the value the team delivers in both the short and long term.
Chandra Knabel is an enterprise architect at SAP.
Photo by Justin Luebke on Unsplash.
