By Diana Tullio
Principal, CC&C Americas
Let’s face it. Software is cool and fun to play with. However, not every organization is ready or truly needs an Enterprise Architecture tool to drive their enterprise or solution architecture efforts.
Clearly, this is a controversial statement.
The point is that a tool won’t solve underlying issues that an organization might have such as lack of standards, process, or needed business and architecture skillsets. A tool might even make things worse… only quicker. It is important to consider the reasons for procuring a tool, the approach used in the acquisition of a tool, and the total cost of the effort of this type of initiative.
Reasoning for Procuring an Architecture Tool
The timing of when an enterprise architecture tool is chosen by an organization is telling. If selecting a tool is the first order of business instead of identifying and understanding what problems need to be solved and how success will be measured, there may be significant risk in a tool investment ever paying off.
There are some very good reasons for an organization to adopt an EA tool at some point though. Legitimate reasons surface as business needs support having more productivity, visibility, and standardization in how solutions are defined and managed.
Only one of these reasons won’t necessarily justify or quantify the return on investment for an EA tool. There may also be other things that an organization must consider such as availability of funds to invest, talent available to drive an implementation initiative to success, or frequency with which architectural activities occur. However, when several reasons start to surface, and the business climate is right, these reasons could be good indicators that an investment may be worthwhile.
Approaches to Tools
Organizations knowingly or unknowingly fall into several historical approaches when it comes to enterprise and solution architecture with respect to tools. The culture of the organization, the aversion to change, the desire for a solid decision based on diligence, and the business circumstances influence the current state.
Aversion to Change: High
Due Diligence: Low
The path of least resistance is to choose to adopt no tool at all. Organizations can have mature processes and team skills without having a tool. This might be the best path for some given their business circumstances. However, it can lead to productivity issues as the number of architectural needs increase. The time saved in not picking and implementing a tool may be substituted with more valuable time being spent by expensive resources in creating and maintaining models manually.
Aversion to Change: Low
Due Diligence: Low
If an organization has a tool or multiple tools, there may be less resistance to change, but there is also less need for diligence. If there are multiple tools, perhaps team members have a favorite tool and there is somewhat of a “religious debate” as to which one is the best. The question is, can the artifacts and models be found when needed, and are standards being followed? If the team is using one tool religiously with standards, this is a great place to be. If not, there could be a lack of visibility to needed models and the possibility of losing knowledge as team members move on.
Pick Any Tool (Need a Basic Tool)
Aversion to Change: Low
Due Diligence: High(er)
Sometimes speed to a decision makes sense. Perhaps the need for a tool is high, but the requirements are straightforward with most tools providing what is needed. In this scenario, there must be enough due diligence to understand the basics of procuring a tool though. What are all the costs over the life of the investment? What type of support is provided? How hard is the tool to configure and implement?
Evaluate All Tools in Depth
Aversion to Change: High
Due Diligence: High
The typical approach for procuring a tool by larger organizations (or those with a high standard for due diligence) is to formerly assess all options. This could be a formal Request for Proposal (RFP) approach that starts with defining the requirements for the item to be procured and requesting vendors to respond with how their solution will best fit the needs requested. Obviously, this takes time and effort to review the proposals that are submitted, discussions/demos with the vendors, and deliberation by the selection team to determine the best solution. It is also important to ask the hard questions to get past the “demo glamor” that can occur when evaluating solutions.
Total Cost of Ownership
While software licenses or subscriptions can be a minimal or large expense depending on the tool selected, this cost is the least of the investment to the organization. There is also the learning curve, potential consulting costs, the time to configure the tool, the time to migrate, and the change management involved in adapting processes and gaining adoption. Don’t let a low-cost tool fool you into thinking that it is a quick purchase that the team will “just figure out.” Even when training dollars are thrown into the mix, there is no guarantee that the adoption needed to change outcomes will follow.
Consider the following checklist to weigh against benefits when gathering the costs for an EA tool initiative:
So. Do You Really Need an Architecture Tool?
Ask yourself the following questions:
- Can your business partners visualize your solutions?
- Do you know how your solutions map to the capabilities of the business?
- Are your models non-existent or a point in time that is long past the current state of your solutions?
- Are there gaps between solutions that your team can’t see?
- Is every model different requiring you, your team, and your business partners to decipher them before understanding them?
- Do you know where you have invested in your technology footprint?
- Are there inefficiencies in your automation, but you can’t determine where and why?
- Are there different versions of the architectural “truth” floating around the organization?
- Is your team spending an exorbitant amount of time creating and updating models?
If you answered “yes” to some of these, a tool might be able to help with resolving the issues. A tool can enable and make life easier. It can never replace the right culture, skills, processes, and standards though.
CC&C has been helping architecture leaders with tool selection, tool and model migration, skills training and architecture team building for almost 20 years. Contact us for more information.
Further Reading & Resources
“Don’t Be a Fool with a Tool”, Jason Bloomberg, August 7, 2014
“Avoiding the Two Biggest Mistakes in Software TCO Analysis”, Evan McDonnell, July 17, 2012
“Calculating the total cost of ownership for enterprise software”, Chris Doig, November 19, 2015
“Six Mistakes that Lead to Poor Enterprise Software Adoption”, Himanshu Sareen
Reviews for Enterprise Architecture (EA) Software, Gartner Peer Insights, 2018
“Enterprise Architecture Software” comparisons and reviews by Capterra, 2018