Conceptual, Logical, or Physical: How to Use Architecture Levels Effectively
A comprehensive set of templates, stencils and a meta-model to support ArchiMate modeling in your organization
The three architectural levels described by the Zachman Framework, which are also found in the TOGAF and ArchiMate frameworks, represent different degrees of abstraction at which the enterprise can be modeled. In order of increasing detail, these are the Conceptual level, the Logical level, and the Physical level.
Often times, especially in new enterprise architecture practices, there is a fair bit of confusion around which of these should be employed for a specific task/at a specific moment in the architecture process. Mixing the levels of detail commonly yields low quality models that fail to get ideas across, which ultimately results in a low value EA function.
This article aims clarify what the best use cases are for each of the levels in order to help architects avoid alienating their audience and make a bigger impact with their work.
Watch the Introduction to Orbus Software video
The Conceptual level is the most abstract of the three. You can imagine it as a very high up position from which you can see everything/most things, but the trade-off is you can’t see them in detail. Conceptual architecture diagrams effectively function as structural models, so they (ideally should) highlight the relationships between key concepts, not how they work. This means they are not concerned with exposing process flow/sequentiality.
Modeling things at this level of abstraction is recommended for creating a clear, concise image of the organization and its strategic objectives. Architects that model conceptual architecture ought to portray fundamental concepts only. This is valuable for consolidating multiple agendas, obtaining buy-in from all relevant stakeholders, and ultimately ensuring alignment with the business strategy. Since conceptual architecture does not go into any technical details, it is very adept for communicating with stakeholders that have a business background, e.g. presenting a business strategy model to management.
It’s important to remember that although it may be tempting to “improve” a diagram with objects belonging to the Logical or Physical levels of abstraction this only detracts from its clarity. Combining artifacts in this manner is guaranteed to confuse stakeholders, so aim to be consistent in your work. Try, for example, to model out the relationships between ongoing investments, business challenges and individual department contributions to the overall strategy on a page. Having a single reference point on the potential decisions and funding options will likely resonate with the audience and foster constructive debate.
Furthermore, an agreed business capability model with an external orientation should offer a solid reference point and allow for a wide range of data to be mapped against the model to support engagement. Where are time and funding currently allocated, and where do gaps, duplication and dependencies exist? By modeling inputs at a strategic level, EA professionals support visibility and agreement of direction, isolate low importance issues and generate superior insights. Once you have established a clear baseline of understanding, you can take a step further – not leap – and advance towards a logical architecture standpoint; but only after you have successfully defined the conceptual touch points on which to concentrate. Gradually leaning into the details keeps everyone in the room on board and also helps to keep focus on the big picture.
Logical architecture describes how a solution works in terms of function and logical information. From an abstraction level viewpoint, it represents a middle ground, sitting between the Conceptual and Physical architectures. Unlike these, however, logical architecture is quite broad in scope. In fact it allows architects to model things both at a high and low levels, depending on the requirements, which makes it very important for the architecture process. For instance, a diagram that leans strongly towards the conceptual side will be more passive and therefore indicative of connectivity, whereas one that is closer to the Physical level will necessarily be more dynamic and better illustrate sequence.
Moving from Conceptual to Logical and creating diagrams at the latter level is a powerful instrument of persuasion. Imagine an architect making the case to management that investment funds should be spent a certain way. It makes perfect sense for them to start from a conceptual model that establishes the context and then follow up with logical architecture diagrams that detail the proposition using concepts familiar to stakeholders with a business background, e.g. Revenue, Risks, Competitors. With the right leveling in place and accurate source data to back up the diagrams the audience will have no trouble keeping pace. In fact, they will in all likelihood prove more willing to accept propositions thanks to this approach.
That’s because simplifying the organizational environment through the application of logical filters to data against the backdrop of the company’s strategy and existing capabilities enables many questions regarding validity and value to be answered successfully. Positioning projects as such usually highlights significant duplication, spending gaps, hidden dependencies and risks that had previously been overlooked. The result? A clear understanding of the problem. Using tools such as Results Chains, for example, or mapping projects to strategic goals and capability models, encourages a logical approach.
When stakeholders can see a clear relation between strategy, capabilities and real benefits internal politics are set aside. What ensues is efficient communication and facilitating it all is the Logical architectural level of abstraction. So go ahead and leverage these resources to better address key business problems, identify and prioritize tactical options, and contribute to more informed decisions being taken.
This is the lowest level of abstraction, so it is very detail oriented. It concerns itself with specific products, data representations, and other technical notions. This is because when designing Physical architecture diagrams the purpose is to enable the real life implementation of a specific technology solution. They act as a guide for the team actually putting the system together. As such, diagram objects point to actual real life software services, server models, CRM systems, network capabilities etc. >This is the lowest level of abstraction, so it is very detail oriented. It concerns itself with specific products, data representations, and other technical notions. This is because when designing Physical architecture diagrams the purpose is to enable the real life implementation of a specific technology solution. They act as a guide for the team actually putting the system together. As such, diagram objects point to actual real life software services, server models, CRM systems, network capabilities etc.
This is why adequate modeling at this level is perhaps more important than anywhere else. This obviously can be overdone, so let yourself be guided by business purpose – not all details are relevant! For most companies, actual deployment is usually accompanied by complications due to last minute decisions or issues that couldn’t be foreseen until the real life stage. However, in organizations with a precise Physical Architecture in place for the solution delivery stage, there usually exists a noticeably lower level of conflict and waste. This ensures fruitful collaboration between project sponsors and project managers, who can understand and deliver on the outcomes within the agreed upon budget and timeframes.
What’s more, thorough end-to-end solution architecture addressing all domain inputs (Business, Data, Application, and Infrastructure) provides a useful roadmap for stakeholders and enables dependencies, risks and budget issues to be identified as early as the concept phase. To be sure, this is quite time consuming but allocating more time in the beginning offers a better payoff later on when your team has a solid case for the project and delivery is planned very well.
Having a firm understanding of the role and value of architectural levels is key for creating effective models and diagrams. After all, it is the function of the EA department to inform, guide and support change initiatives in an organization. If we boil it down, the way they achieve this is through productive communication, which means architects have the responsibility to get insights and information across to the wider business. That is as integral to their activity as is identifying these insights in the first place.
By adopting the correct level of abstraction, i.e. the one most relevant to their audience’s background and the task at hand, the EA team ensures their deliverables generate maximum impact. Whether managing an integration program following a merger, or looking to digitalize a number of organizational processes, adequately leveling and positioning your work is a vital step in creating a practice that addresses issues correctly and achieves the desired outcomes.