Page tree

Architectural Thinking Framework

Skip to end of metadata
Go to start of metadata

A technology component represents a software or hardware resource that hosts or interacts with other technology components. It executes computational behavior or stores and processes data. Technology components are used to support applications.

A technology component can compose other technology components, for example, an ‘operating system’ consists of a ‘file system’ and a ‘user interface’.

Technology Components can be related to other technology components. A ‘database’, for example, runs on top of an ‘operating system’ and a ‘hardware server’.

Why is it important to manage technology components?

  • Categorising technology components by technology domains helps to identify redundant technologies.
  • To know which technologies you already have is mandatory to assess new technologies that fit with legacy.
  • Assigning operation and maintenance costs to technology components is mandatory for IT cost controlling.
  • The cost of IT-application can be calculated by summarising the cost of supporting technology components. Thus, the cost of IT can be assessed in comparison to its business value.

1 Comment

  1. Anonymous

    I'm struggling with the definition of Technology Components and why they should be separated from Applications. Aren't they both just reusable and combinable IT building blocks to support Business Capabilities?
    First, I would be really careful with "hardware" and "hosting". With the current data protection laws, it is not enough to simply identify on which server which application is hosted. The business has to be able to say, which personal data of citizens of specific country is stored with which providers in which countries for which purposes, and where this data is being transfered, and whether all providers fulfill the security requirements. This turns "hosting" very much into a business problem, and pushes "hardware" from the pure CMDB corner very high up into the architects agendas - just maybe not on the level of individual servers, but company's own and 3rd party data centers. So, if for each Technology Component pertaining to "hosting", I have to document the Business Objects, country, provider, processing activity, information flow - then for me the place of such a component in the architectural model is exactly where the Applications are, not somewhere "beneath" them.
    Second, the separation of Technology Components and Applications makes it difficult to find a logical place for services and integration platforms. E.g. where to place LeanIX? It "provides useful business functionality to its users", "stores owned business objects" -  so it's an Application. But it has costs, which are attributed to Technology Components, not Applications. So for IT cost controlling purposes, I have to document LeanIX once more as a Technology Component and map it to LeanIX-Application, and thus maintain the same data twice with slight variation - but that's me. Most IT colleagues that maintain architectural data would simply omit one of the steps. And speaking of costs, "the cost of IT-application can be calculated by summarising the cost of supporting technology components" is not exactly true, just consider SAP platforms or AWS. I believe in capability-based cost calculation as shown in AT18 blog post, and for that, why introduce additional complexity by putting applications in-between?
    And third, now that the borders between business and IT are blurring, where should the line between "provides useful business functionality to its users" and "used to support applications" be drawn? Isn't "Software Development" a Business Capability in it's own right? Data scientists are a very good example: they are not pure IT folks, but colleagues from classic business departments and - increasingly - digital programs. And for them, SQL Server and Jupyter Notebook are concrete tools to perform their very well-defined and tangible business functions, and not some ominous "application support".
    To conclude this very long comment, I'm not criticizing or seeking confrontation here. I'm sure this model works for most companies and is a good practice for a reason. But the requirements are changing, and this also challenges the habitual ways of documenting the enterprise architecture. This framework already addresses so many lean and innovative approaches, and that simply makes me want to share my current thoughts with you. Thank you.

Write a comment…