How do you pick the perfect business architecture tool?

In my role as an Enterprise Architect for the Montana state government, clearly defining business architecture goals has been paramount. We aimed for goals that not only focus on technological improvements but also align with the needs of our stakeholders, including the citizens we serve. In line with SAFe's principle of 'Build incrementally with fast, integrated learning cycles,' we’ve adopted an iterative approach to goal-setting, allowing for adjustments as we go along.

The "perfect architecture tool" may be a myth - no such thing. Rather a collection of tools may be required - and contingently dependent on the situation in which they are used and the people using them. There is no single tool that is appropriate for all situations.

You need to know where you are before deciding where you want to go to, and hence how to get there. Your business architecture goals come later. So, what already exists within the enterprise? Are there clearly defined architecture roles and responsibilities? A governance structure? What's your budget? Is there a maturity assessment? If there are, they may need updating and gaps filled. If not, you're going to have to make a start on building these first.

Choosing the right business architecture tool requires considering various factors to ensure it meets your organization's needs and objectives. 1. Identify Business Requirements 2. Assess Features and Capabilities 3. Evaluate Usability 4. Consider Technical Aspects 5. Analyze Cost and ROI 6. Conduct Vendor Evaluation 7. Perform Demos and Trials 8. Make an Informed Decision By thoroughly evaluating these factors, you can select a business architecture tool that best fits your organization's needs and helps achieve your strategic objectives.

First of all the ArchiMate is not comperhensive architecture framework, ArchiMate is primarily a modeling language used to describe, analyze, and visualize different aspects of enterprise architecture. TOGAF is formal architecture framework which includes guidelines for creating and using architectural models, but it doesn't prescribe a specific modeling notation. TOGAF is broader in scope and covers a wider range of enterprise architecture aspects, including governance, methodology, and tools. Archimate is often used within the TOGAF framework to create detailed architectural models as part of the architecture development process.

Again the question is phrased as a singular selection one. No, there are positives and negatives about every 'framework'. There should be no assumption of "pick one". Rather an eclectic multimethodological approach that uses appropriate parts from many frameworks in a "ways-of-working" that again is contingently dependent on the situation. No "one-size-fits-all" approach.

As another commenters have noted, you need to adapt a framework, or aspects of multiple, to your align with your organisations needs. You also need to be cognisant of prior or existing attempts within your organisation to implement such and what tools were/are in use. Once you know what's out there, next you should bring it under governance, assess it and consult stakeholders on potential impacts of change. Once you have buy in, then you can start selecting and tailoring aspects of frameworks to suit your organisations maturity and culture.

Archimate is not a EA framework, it is a modelling tool that cane be adopted and used within TOGAF framework (tailored to the business specifics needs). Archimate from TOGAF perspective can be mapped to the Enterprise Continuum where all enterprise assets /models are stored,

My early months in this role had me evaluating several frameworks to see which fit our complex governmental context best. After a thorough review, we found that TOGAF provided a robust structure but allowed us the flexibility to adapt it to our specific needs. A significant part of picking the right framework involved assessing our organizational culture and how well the framework's principles could be integrated.

We prioritized scalability, security, and ease of integration when we evaluated tools. Given the state government's future growth plans and various departments with which we needed to collaborate, these were non-negotiables. In line with SAFe's principle to 'Apply systems thinking,' we also considered how the tool would fit into our broader ecosystem, including other systems and processes.

Stakeholder involvement was crucial during our selection process. We set up a cross-functional team including IT architects, project managers, and even some of our executives. This aligns with SAFe's principle of 'Decentralize decision-making.' We also implemented a scoring system, akin to SAFe’s Weighted Shortest Job First (WSJF), to assess various tools based on multiple factors, ensuring we chose the most cost-effective solution that delivered the maximum value.

Start with a review of what's already in use by the organisation. And not just tools, but also management (and other) techniques employed throughout the organisation - they often go together - and existing tools include spreadsheets, presentations etc. Develop a strategy for tooling (it will rarely be the singular) ensuring stakeholder requirements are articulated and met as they will ultimately own their aspects of the tooling. Then develop a high-level implementation plan for tooling - that plan can include a selection process. Don't dive straight in - delay any major changes or introductions of tooling until the organisation has at least bought in to the journey ahead of them, which should be charted first.

One most important feature for me is the UX. The tool needs to be complete and most of all easy to use. As an EA, i don't mind going through a complex process to maintain the information within the application (going through too many screens, having to create an element beforehand, stick to one and only one paradigm...). It may be cumbersome and annoying but, well, job needs to be done. BUT, the bigger your team, the harder for you to keep valuable information IF it requires your team to master ALL too many processes. And even worse: with a bad UX, your stakeholders will have hard time finding the information and understanding the information. If they don't get it, stakeholders being stakeholders, they won't be interested, they won't help.

Steps 5 and 6 go together - frequently iterate both the plan and the implementation. If you're doing a beta first, and that's not a terrible idea, make sure the participants are representatives from multiple business areas, and not just a small 'target' group derived from the primary business sponsors.

Planning the implementation was equally important as selecting the tool. We adopted SAFe's Program Increments (PIs) to align our implementation with our broader organizational goals and timelines. Clear roles and responsibilities were assigned to ensure everyone knew their part in this journey. Training and change management were integral to our plan, enabling us to transition smoothly.

In line with both EA responsibilities and SAFe principles, continuous improvement is a focal point in our strategy. We regularly solicit feedback from all levels within the organization and make data-driven decisions to update and tweak the tool. The principle 'Inspect and adapt' from SAFe guides us here, encouraging us to iterate and evolve constantly.