How do we perform an architecture assessment process at Yalantis with TOGAF?

When you’re looking for a reliable team to perform an architectural assessment, you should make sure their approach is right for you and covers your business needs. There are different assessment approaches, including The Open Group Architecture Framework (TOGAF) and the Architecture Tradeoff Analysis Method (ATAM), each of which has its own use cases and architecture checklists.

In this article, we will share how we conduct the architecture assessment process at Yalantis with the TOGAF approach and draw your attention to important aspects of each stage.

But before we move to a step-by-step assessment, let’s look at what issues might lead you to decide that your business needs an architecture assessment.

Each of the scenarios below indicates that you’re missing something important in your business because of architectural issues. An architecture assessment can help you see all the weaknesses of your system and identify the main problem and suggest a unique solution that perfectly fits your business processes. 

1. You can’t grow your business effectively because of poor integration or architectural capabilities. Let’s say you can’t scale the number of orders, as there are bugs because of some integration and the quality of orders is being compromised. Eventually, this slows down your business processes, and you can’t grow your business because as the number of orders increases, the number of problems does as well. You may also see the need to design and implement a high-capacity and defect-tolerant architecture for your software ecosystem.
2. You want to achieve a competitive advantage. You’re probably thinking about becoming better than your competitors in terms of the variety of products or services, payment methods, website speed, delivery speed, or delivery channels you offer.
3. There are performance issues that have gone unfixed for a long time. You may have performance issues with your website or applications. Waiting five to six seconds for a site to load is likely to make your customers leave. This means the quality of service will eventually decrease, and so will your revenue.
4. An expected sale or investment round is coming. In these cases, a company usually performs an architecture assessment of the technological aspect of the company.
5. The engineering team is frustrated and you have a high resignation rate. This is often the result of problems with the architecture of processes. For example, employees may leave because of complicated and inefficient bureaucratic processes.
6. There are problems with the operational activity and personnel. A lot of manual processes or slow processes around some employees can slow down all business operations.
7. You need to increase the velocity of your development team. When a company achieves a certain level of success, it’s necessary to upgrade its systems to achieve further progress. To make such changes effectively, the company needs a team of engineers, and to make such changes quickly, it needs a large number of them. You may plan to expand your team from four to 20 developers. In this case, it’s important to conduct an architecture assessment to determine how these people will effectively cooperate. If your architect correctly splits the work into teams and teams into the system, then a large number of people can work together efficiently. If teams are not decomposed correctly, there will be unnecessary dependencies between systems and teams, leading to low velocity.

Now that there’s an understanding of when to pay attention to your application architecture, let’s take a step-by-step approach to architecture assessment.

There’s no universal software architecture assessment template that fits all cases. The Open Group Architecture Framework (TOGAF) can be a good choice if you need to perform an assessment for a large company, while the Architecture Tradeoff Analysis Method (ATAM) is better for smaller companies.

We want to take a closer look at TOGAF, as we use this architecture assessment framework at Yalantis. In addition to its great usability, TOGAF provides an integrated approach to the design, planning, transition, execution, and management of an enterprise information technology architecture. Below is a comprehensive diagram of what the complete TOGAF cycle looks like.

If Yalantis experts perform an architecture assessment for a client, the Yalantis architect covers steps A through D/F. But if Yalantis experts also conduct product implementation, then we cover the rest of the steps as well.

According to the TOGAF, software architecture can be represented as three main layers:

• Business architecture, which defines the enterprise strategy, management structure, and key business processes
• Information systems architecture (data architecture and application architecture), which describes the business processes and rules, system structure, technical framework, and product technologies for a business or organizational information system 
• Technology architecture, which defines the structure and logic of the software and hardware environment required for business applications and access to necessary data; includes all supporting infrastructure: networks, servers, processing, etc.

At Yalantis, we believe the best practice within this architecture assessment example, TOGAF, is to run three core stages according to the image above — business, application, and technology layers. By doing this, we can see the whole picture of the architecture assessment process. Thus, we can update phases inside each layer during our work. If we don’t run the layers in parallel, some of the major processes become invisible, thus affecting the result of your company.

Read this article if you’re interested in learning about the core app development stages we follow at Yalantis, implementing development best practices, and ensuring development continuity and stability. Or try to explore more about microservices architecture in banking.

Let’s look at stages A to F of TOGAF, which Yalantis covers.

The architecture vision stage is where we start with the TOGAF approach. The goal of this stage is to understand stakeholders’ main requests and get the necessary information for your future architecture vision. Key stakeholders are key players, who the architecture assessment starts with, and who the process always refers to.

During the architecture vision stage, Yalantis experts need to define key objectives, stakeholders, and the strategy for interacting with them from the very beginning of the working process. To do this, we take the following steps:

Step 1. Identify key players who are influential and of interest

Key players might be the CEO, COO, product owner, technical manager, and CTO. It’s best to involve as many stakeholders as possible at the early stages to find out the main things they want to achieve. That’s when we use Mendelow’s matrix. 

Step 2. Determine a strategy for managing stakeholders

After identifying the key players, we determine how to interact with the main stakeholders in the client’s company using stakeholder management and stakeholder engagement approaches. At this step, we consider and plan how to schedule meetings or other interactions with key stakeholders. 

3. Analyze how the business operates

Having identified the core objective, we gather additional information, which may include the following:  

• How the business works (what to create and sell, where to get this product or service)
• Who customers are (who the target audience is)
• How and why to serve customers (through which channels, applications, or personal connections)
• What competitive advantages your company has (better website UX, better support, more convenient payment methods, availability of an expensive domain name, etc.)
• What business processes are (external processes are tied to how you interact with your customers and suppliers; internal processes are tied to how you evaluate the effectiveness of your business)
• Where manual operations exist
• What software systems are within the company (purchased or built)
• Who the company depends on (external vendors)
• Which external vendors there is a hard dependency on (hosting, CRM, service providers, etc.)
• Which legal requirements must be followed in your business (financial regulations, GDPR, user data requirements, regulation and licensure in engineering, etc.)

After we’ve gathered all the necessary information at this stage, we can move on to the next stage of TOGAF.

At the second stage of TOGAF, our goal is to craft baseline and target business architectures. 

The baseline architecture (commonly referred to as an “as-is” architecture) is a set of products that describe the existing software, the key business processes and systems, technical infrastructure, and actors that interact with each other. 

The target business architecture is almost the same as the baseline architecture, the only difference being that the target architecture is what you want to achieve in one or two years.

From baseline to target business architecture with domain-driven design (DDD) decomposition

DDD decomposition is a method for understanding which entities are responsible for which modules in the architecture and properly allocating them. 

• The purpose of DDD decomposition is to redistribute entities between available systems and redistribute system responsibilities and possibly reassign them. 
• Eventually, DDD decomposition ensures that each business subdomain corresponds to a different part of the business.  As an example, let’s imagine we have a back end, an admin panel, a website, and marketing pages in our baseline architecture. The goal for the business is to make a mobile app and collect analytics.

If some of your services are similar to an existing generic service, then think about replacing them with ready-made software. This allows you to remove the distribution of logic between services and avoid unnecessary dependencies between services (the fewer dependencies, the more reliably your services will work). Potentially, this will save developers’ time and your company’s budget.

At this point, it’s also worth keeping in mind that we’re breaking down architectural systems so we are able to buy and not build those systems for which a particular company does not have a competitive advantage. 

Eventually, the example above turns into a target architecture where we have divided the main API into three pieces: a back end for the app, a back end for the front end, and background cron jobs that have started to connect through the message bus. The message bus also makes it possible to connect the data platform for analytics to the ML solution for recommendations. Also, for the landing pages, we have moved away from a custom solution to a SaaS solution to save developers time. Finally, we have introduced A/B testing for the website and mobile app. 

Our example demonstrates what the raw baseline architecture is and what the completed target architecture looks like with the DDD decomposition approach.

This stage covers both data architecture and application architecture assessments. Let’s take a closer look at these concepts.

Data architecture

The baseline data architecture is what we currently have in the architecture. At this phase of Stage C, we check the following: 

• how data is exchanged 
• in which systems data is stored
• how data (i.e. user data) gets from one system to another
• how securely data is stored and transmitted

The target data architecture helps us solve issues connected with security during transit and at rest, data duplication, and unnecessary synchronization issues. The first and one of the most important rules is to minimize data duplication, which can eventually lead to data inconsistency. 

A target data architecture assessment is conducted to understand where data is copied to eliminate extra data transfers. Excessive data transfers create unnecessary possibilities for errors. If data is stored in multiple locations, there’s the possibility of potential data inconsistencies. 

When working with open source enterprise data management systems, it’s common to use multiple storage and processing layers in the data architecture, which often means storing data in multiple formats to optimize access. This can even mean duplicating data, which in the past might have been viewed as an antipattern because of the expense and complexity. However, with newer systems and cheap storage, this becomes much more practical.

What doesn’t change is the need to ensure the integrity of data as it moves through the system from data sources to final storage. When we talk about data integrity, we mean being able to ensure that data is accurate and consistent throughout our data pipelines. To ensure data integrity, we must know the lineage of all data as it moves through the system.

At this point, your expert team also eliminates any delays. For example, say there are a lot of problems with delays in the data warehouse, namely when reporting is done daily, which is a long process for most companies. Modern log streaming systems allow reports to be updated in real-time, in a matter of seconds. 

You also may consider detecting cloud security risks and empowering security in your application development due to the predicted number of threats in 2022. Our experts can help you out here due to our extensive cybersecurity expertise. 

In the next section, we describe the application architecture as part of the information systems architecture and answer a constant question: To buy or to build?

Application architecture

During the application architecture assessment phase, we clarify what systems our app consists of and try to optimize it with the buy or build method. According to this method, we should rationally examine what’s worthwhile for a company to build on its own and where it’s more profitable to buy existing software.

When to buy

As we mentioned above, our advice is to initially try to buy all software that is not for competitive features. Why spend countless hours having your best people architect a solution that already exists and is proven in the market — or even hire new people to do so? 

If you’re looking for even more concrete evidence as to why you should buy a ready solution, then estimate the initial internal development costs as well as the ongoing maintenance required. The burden of product development, quality assurance, maintenance, platform migration, and patch fixes are owned by the solution provider, while in-house development might require years of continued work beyond the initial project scope.

Pro tip: If you want to buy a system, you can easily compare SaaS solutions on G2, the world’s largest marketplace where companies can discover and review technology. Another option that’s actually free is to use an open-source solution. In this case, we only need to host the solution ourselves, but the code itself is maintained by the open-source community. 

When to build

First and foremost, we build a system when it brings the client’s business a competitive advantage. Also, when applying unique intellectual property or creating genuinely novel capabilities for end customers, custom development may be ideal. Another time when you may choose to build your own solution is if there is no existing software that fits.

Often, technical specialists want to build all the necessary software themselves. But such a desire should be a red flag. Typically, it means that the DDD decomposition phase has been done incorrectly — namely, that the business architecture has been broken incorrectly into other systems. In that case, the architecture should be reconsidered.

Let’s cover how it looks in the technology layer of TOGAF and how to make efficient technology choices.

The technology architecture baseline allows you to see what we have in the architecture eventually. Then, based on the target architecture, we can decide whether existing technology choices are sufficient or whether we need to change them. After making a decision at stage C between buying ready-made systems or making your own, now we can decide on the technology architecture for systems we’ve decided to build on our own. 

If you decide to build your own system, you have to choose languages, databases and hosting. Of course, your team of experts can find the best solution based on your business needs and the job market (for example, which engineers are easier to acquire). But it’s also useful to take advantage of additional resources when choosing a technology.

ThoughtWorks consultants have a blog to guide you in choosing technologies that are currently working on the market. Once or twice a year, updates to their technology radar help experts decide what’s worth using and what technologies or tools should be ignored. 

• The adopt circle contains technologies that are recommended for implementation in all organizations, both large and small. 
• The trial circle gives you technologies that main business processes shouldn’t rely on. Technologies that have been popular on the market for only one or two years are usually high-risk and should be avoided for important business processes like those on which your sales depend. 
• The assess circle is about technologies that have not passed the test of time, as they are brand-new. These are not worth using for mature and established businesses. 
• The hold circle contains technologies that should not be used by any business for any processes.

We also advise being guided by the amount of time technology has been around. If technology has been actively used in the market for more than five years, it’s most likely established and will be popular in the next five years as well, making it safe to use. 

Read also: Choosing a tech stack for full-cycle web application development

At this stage, we need to break down the scope of work into several solutions. To do that, first, it’s necessary to understand the entire scope of work. For this, we compare baseline and target architectures and identify the differences between them at all levels: business, data and application, and technology. 

After that, we need to make a separate solution for each difference that we have identified previously. Usually, the solution consists of a user story map, infrastructure diagram, and tasks for developers.

After stage E, where we turn all our previous work into a visual scope, we move to the final stage of the TOGAF approach.

The goal of the last stage is to create a comprehensible roadmap. To do this, we need to go through an architecture checklist to understand who exactly is going to perform the scope of work and how many teams are needed. The solutions created in stage E should already be estimated and arranged in the right order in the roadmap. If there are any dependencies between solutions, this should be taken into account and mapped.

Crafting a roadmap is often the responsibility of business owners. If Yalantis performs the architectural assessment, we suggest our version of the roadmap so there’s an understanding of when everything will be implemented. But even then, the final decision is always up to the business owners.

As a result of going through our full architecture development cycle, we have:

• completed the entire architectural part of the project
• clearly understood change requests
• analyzed the architecture
• offered solutions
• attained a delivery roadmap

After the architecture development cycle at Yalantis, you just have to make sure that your roadmap is executed and that the solutions we offered are implemented by your developers (Stage G according to TOGAF). After that, you can evaluate the results of the work (Stage H) and start the next cycle of architecture assessment. 

Usually, in product companies, such an assessment cycle is carried out once or twice a year. For fast-growing companies, there is a need to conduct architecture assessments once every quarter. 

Yalantis experts can offer IT consulting services in case you have any questions left about TOGAF. But we would also like to mention what you should pay attention to when choosing the team to perform your architecture assessment.

When it comes to choosing who should perform your company’s architecture assessment, there are three options.

#1 Perform an assessment with your internal team

Typically, you can do such an assessment with the help of your solution architect, CTO, or even lead developer.

The benefit of this approach is that it can be done rapidly and at no extra cost. The drawback, however, is that it usually requires more skills for solution architecture evaluation than it does for implementation. If you’re interested in lowering development costs, you can find an external partner for the assessment and then use a relatively less skilled in-house team for the actual implementation.

#2 Work with a consulting agency

You can choose between consulting agencies such as McKinsey, Bain & Company, and PwC. The peculiarity here is that they only perform an architecture assessment but don’t do the architecture implementation. In this case, you will have to use your internal team or another vendor for implementation. 

In general, this approach works well when you want to evaluate your business strategy first and then adapt the architecture to the new strategy. If your goal is to evaluate your internal team and their choices, then this option is perfect as well. The disadvantage is that working with a consulting agency is more costly than other approaches, and it only makes sense for companies who can easily afford it.

#3 Work with a software engineering company

You can also get help from an independent software engineering company. A software engineering company can cover both assessing your architecture and implementing the scope of work. 

This is the best approach when you want to achieve results as quickly as possible, involving external development resources. Working with a software engineering company is the fastest way to get your business idea to the market. Why? First, the company can start development immediately after the assessment. Second, the company will provide you with a development team, and you will not have to spend time on hiring and onboarding.

Yalantis can both cover your solution architecture assessment with the TOGAF or ATAM approach and implement your solution. We also offer infrastructure assessment as part of our site reliability engineering services. We provide multiple services, including development team augmentation, custom software development, and IT consulting.