Archive

Monthly Archives: February 2014

This is the second blog post on Enterprise Design Model. In this blog post we will take a next step in explaining the Enterprise Design Model, the application of IT. In the blog post Enterprise Design Model – Introduction we described the structure of the Enterprise Design Model. It is divided in three architectural type columns (i.e. Structure, Behavior, and Knowledge), which have been inspired by natural language, where a sentence has a subject (structure), a verb (behavior), and an object (knowledge).

When an organization decides to increase efficiency of the business by applying IT we see the following detailing of the Enterprise Design Model.

  • The business capability is partly realized with application capabilities, which consist of application services exposing application functions.
  • The business solution is partly completed with application solutions, which consist of application modules and application interfaces providing collaboration, access to application services and running organizations
  • The business component is partly fulfilled by technology components, which conduct of platform services delivering technology functions.
  • The business system is partly built with technology systems, which consist of platform devices and infrastructure nodes connecting networks, hosting technology components and deploying application solutions

Enterprise Design Model 2.0

This diagram illustrates the Enterprise Design Model applicable for business and IT. Equally as for the Enterprise Design Model for business and organization there are in total 14 or more models. In this blog posts only the IT specific architecture model are explained, complementary to the business and organization architecture model for the first blog post about Enterprise Design Model. Jon H Ayre wrote an excellent blog post explaining the architecture models for business and IT, which we have adapted to the following descriptions to start with:

Application Layer: Describes the capabilities, which deliver solutions to support the business layer. In an IT environment it contains the automation of business processes with application services, which are realized by applications functions processing data.

  • Capabilities (Application Behavior)
 – Illustrates the internal application services needed by the business (including IT) to allow it to undertake the processes described in the business layer.
  • Solutions (Application Structure)
 – Elaborates how the application services interact with one another to fulfil the needs of the organisation model and thus provide the desired customer experience.
  • Data (Application Information)
 – Captures the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the capability model (and vice versa).

Technology Layer. This layer could easily be rephrased as Infrastructure Layer, especially in a non-IT environment. In describes the systems required to support the solutions describe in the application layer. IT-specific it describes required components and sources exposed by platform and infrastructure service (e.g. messaging, processing, storage,) to run applications functions and store data.

  • Components (Technology Behavior)
 – Illustrates the individual technology components available to the business to perform its daily activities.
  • Systems (Technology Structure)
 – Elaborates how the technology components interact with one another to fulfil the needs of the solution model.
  • Sources (Technology Knowledge)
 – Captures the sources of the raw data described in the data model. In an ideal world, these sources will be derived directly from the data model, but in reality sources may duplicate data, or separate related data as a result of the choices made in the Component model. This model should therefore identify how the duplication and re-combination of data will be handled.

As Jon H Ayre already mentioned in his blog post there are a lot of models to consider, and we have to start somewhere. The majority of “traditional” organisations start by developing the Organisation model from a business perspective or the Solution model from an IT perspective. The pitfall of the last model is it often falls to IT alone, acting on a variety of unaligned instructions from many interested parties. It is also best to start with the Service Model in keeping with the value (proposition) oriented approaches that many business architects adopt, and then work left to right and top to bottom.

And Remember… One of the challenges with Enterprise Design is that when you explain it in words, it always sounds more complex than it actually is in practice.

note: TOGAF® is a registrated trademarks of The Open Group

© 2014 ARTe Group BV – All rights reserved