Your corporation needs to upgrade its business architecture modeling tools. What are your options?

We've seen so many tools filled with data not being used. Start from conversations that people want to have, and translate between specialist languages used across the enterprise. Make facts about the business, its customers, organisation and products easily accessible, using compelling narratives. Only upgrade if it helps with this task.

The answer is simple, most business modelling tools aren't actually BUSINESS modelling tools, they model processes, they model systems and they model organizational structures. They assume the 1980s model of the value chain and then aim to industrialize that through processes. In the world of AI that sort of approach will not work, we need to model the business as a value network of collaborations that work both internally and externally to drive towards the corporate goals.

Adopting composable thinking is crucial. The evolving business environment and rising expectations necessitate tools that efficiently create, communicate, and manage business architecture. Composable thinking, emphasizing modularity and strategic alignment, proves essential. This approach elevates the quality of business models, fostering collaboration among architects. It enables seamless integration with enterprise architectures, facilitating effective capability analysis. Organizations leverage the latest standards and best practices, ensuring a proactive, competitive stance. Embracing composable thinking positions businesses for optimal business architecture upgrades in the ever-changing business landscape

Don’t become obsessed about what tooling you need! Work out what are the big rocks that you need to solve as an organisation and then use appropriate data / information to work that out. This needs to be pragmatic and high level. For example if you’re architecting how you buy and a merge a company, what are the high end impact things you need to sort. Use 80/20 rule to identify if it’s say resources and roles identify what should be consolidated via a capability model and focus where the highest costs are. If it’s understanding value chain and understanding where you have dwelling time use appropriate model to determine. Gradually build out the model / tooling as you solve big rock items.

One of the key things with architecture is to help everyone understand for me the target group is not the architects it’s the people that are deciding, and decisions are both high and low

Today there are several new tools disrupting the market such as Ardoq, which are built for the cloud and have a higher focus on collaboration and dynamic usage of the tools. It's not enough to have a tool that can held lots of compliance data. A big topic is how is the tool being updated with data. Without the capability of a tight integration it is really difficult to keep up a tool to represent the organization. Visuals: the EA tool needs to excel in building great visuals if the data to share with the organization: otherwise it remains obscure. Collaboration: it should be simple to setup and trigger actions for different owners to update the data without having to enter into the tool, but responding to dynamic forms to add information.

In Developing countries I would recommend a hybrid approach when adopting business architecture tools. This means, buying tools which can be installed on local machine and have the capacity to sync into cloud. So that the users can work from any machine and still have the ability to access and continue to working from where they left of on their locally installed app.

Over the past decade, there has been a growing consensus on the role of business architecture – to encapsulate a big-picture perspective (BizBOK). However, a significant challenge arises with older toolsets, most of which predate this decade! This challenge is referred to by Gartner as the issue of non-consumable business architecture. My recommendation is to explore toolsets with a focus on end-user adoption, making architecture easily digestible; check out the low-code platforms. Not only do they exhibit enhanced performance and aesthetics, but they also offer the flexibility to adapt to evolving use-cases. Recognizing that web-based business architecture is crucial for delivering decision-making. Collaboration and web is key for BA.

Some other options/choices to be considered will be around Multiple tools vs Single tooling strategy. Multiple tools will probably offer you some specific 'best in class' capabilities but will mean standardisation could be difficult, probably more costly to license and maintain and train users vs a one size fits all approach.

Like a carpenter using multiple specialized tools tailored for each task, adopt a toolkit approach with specialized modeling tools for strategy, capabilities, data, processes etc. rather than an all-in-one solution; integrate via APIs and focus on the interplay between tools to enrich insights, while custom building any missing niche capabilities in-house later. This balances customization, cost and time to value over a single rigid solution.

Choosing the optimal tool for upgrading business architecture modeling is a multifaceted endeavor. A comprehensive assessment entails scrutinizing diverse facets including business architecture goals, standards, stakeholders, and costs. Crucially, aligning tool features with modeling requirements is paramount, as is fostering seamless collaboration among stakeholders. Evaluating data sources and formats is pivotal, alongside selecting features that bolster modeling activities. Only by meticulously weighing these factors can one ascertain the most fitting tool for advancing business architectural endeavors.

Before choosing a tool, think about your strategic planning processes. How do you set new goals and objectives and how do you translate them into strategic initiatives ? Depending on the maturity level and the length and breath of your strategy cascade, the required tooingl capabilities will be different. For example, a customer told me they don't have the maturity to model business capabilities so they stick with a portfolio of business services.

The evaluation criteria could include multiple factors including : 1) Outcomes you want to achieve with this tool - capabilities, processes, strategic planning, portfolio prioritization 2) Alignment to industry standards / frameworks out of the box with no/minimal development changes. This could include Zachman, BaBOK, BIZBOK, TOGAF among others 3) Ability to integrate with other tools (via APIs, endpoints, data exports) 4) Data and technical standards/policies - check if data can be stored in certain regions, on-prem vs. cloud, web-based vs desktop, technology biases, and constraints 5) Costs

Choice should also be driven by the intended culture of process modelling. Some really lightweight tools with generic notation can be a great fit if company is targeting a truly wide reach and operationalising far below a middle management level. Comprehensive solution does naturally narrow the spread of process modelling across the org units and org levels, makes it more of a project or process office tool rather than common source of process reference.

Tooling decisions are important because they shape the processes they support in many ways --including how much you spend on the tools! Most of the screwups I've seen do not happen because people forget features or details while comparing. It's because they forget the fundamentals. The most fundamental is what is at stake & how much can you afford to spend on the tool itself vs the work that uses it. I've seen teams that succeeded in integrating really good tooling but spend so much time on the tooling they have insufficient time to do the real work. How much to spend on the tool depends on what is at stake and your time & money budgets. For small jobs, a unified tool is best. For long term ones, it pays to optimize the tooling.

The advice provided by the question is good. I would add this. When you build a rubric to score, convert abstract benefits like integration, ease of use, visualization & collaboration features into quantifiable hard or soft benefits. Chocolate-coated graphing (say) might be nice to have becasue it saves time. Where? How much? You might think quantifying benefits is error-prone, and you're right. But if you're objective (and not always round up on your favorite tool), the law of averages is on your side. You'll be surprised how close you'll be in the aggregate. In your rubric include the tool total cost of ownership. Finally, reduce your cognitive burdens. Eliminate choices that don't have must-have capabilities right away.

Consider the consulting expertise of the vendor in your industry with examples from your region, that you can visualize. Ask to meet with the team that would be involved

When looking at how to evaluate you should also be seeking the input from your procurement team to ensure your approach is fair, will get what you need out of it and is within any company procurement policies and guidelines.

With an interdisciplinary group of professionals evaluate the different presentations, documentation, features and general capabilities of the tool and objectively evaluate the results of a POC against the objectives of the need for the new tool.

Evaluation involves assessing tools against specific criteria. Consider factors like modeling flexibility, scalability, user interface intuitiveness, and vendor support. Conduct trials or demos to gauge practical usability. Assess the tool's compatibility with existing systems and its capacity to streamline workflows.

A major piece to remember here when looking at this upgrade is that it shouldn't be done any differently to other projects that would be architected and then run as a project. Those steps should be followed, the outputs of this hopefully providing a solid implementation / migration path. Specifically though as the Biz Arch team - be aware of the impact of this change on the team (change, skills, adoption, how are in-flight projects impacted, have we allocated resource to support the change etc...)

The partner you choose to implement and train needs to have strong expertise in the tool. I have had two projects where this was not the case and we ended up with a mediocre result desire being approved partners. Then had to correct this by hiring another company. Make sure you build integrations to feed data to the EA tool. Uploading data manually is a losing job: very hard to catch up. Ensure you have built a powerful visualizations that will demonstrate the value. Ensure you build workflows to involve different stakeholders to update data that requires user input, such as technically) business evaluations, etc.

Aten??o a parte de integra??es com demais plataformas e bases externas de fornecedores que possam ajudar a manter informa??es de ciclo de vida atualizadas.

Preferably with a mixed internal and external team from the manufacturer and also preferably with a third party with recognized experience in the same tool and in configuration, migration, production launch, stabilization and support processes.

Implementing a new business architecture modeling tool requires careful planning. Develop a detailed implementation strategy, including training programs for the team. Consider a phased approach to minimize disruptions. Collaborate with vendors for support and ensure that data migration processes are seamless.

In the latest State of Enterprise Architecture 2024 report, the stack of skills available indicate most IT organization are struggling to find Enterprise Architects. Skilled EAs are incredibly difficult to find available. So when we make our choice of tools we need to be prudent to understand the adoption and usage of these will have to be spread out and not limited to a specialized team in the organization. Low-touch and ease of configuration and adoption is important in the longer run.

Beyond the immediate steps, consider factors like long-term vendor viability, ongoing support and updates, and potential customization options. Evaluate the impact on existing processes and ensure a smooth transition. Prioritize data security and compliance. Regularly review and update the toolset to stay aligned with evolving business needs and technological advancements.

One pertinent example of the significance of upgrading business architecture modeling tools lies in the realm of a multinational corporation grappling with disparate systems and processes across its global footprint. By adopting advanced tools, they streamlined operations, harmonized diverse architectures, and fostered a culture of collaboration, catalyzing transformative growth. Such instances underscore the transformative potential inherent in judiciously upgrading business architecture modeling tools.

When updating enterprise architecture tools, it is important to consider compatibility with existing systems, data security, total cost of ownership (including licensing fees, maintenance, and support), and impact on business processes. Additionally, it is crucial to consider the scalability of the solution to accommodate future company growth and its integration capabilities with other enterprise applications and systems.