Enterprise Architecture

A Pragmatic Approach Using PEAF


◄◄◄ Previous Page         


          Next Page ►►►

The X-Requirements are fundamental core requirements, that Enterprises should consider applying to Tool Vendors, when evaluating EA Modelling Tools. These are the single most important features that, if not present, will seriously limit your use of a tool. The other detailed Tool Requirements documented elsewhere in PEAF are useful also, however, these much smaller set of X-Requirements can be used as critical gating criteria, to reduce a large number of Vendors down to a smaller set, for detailed evaluation.

They are split into three distinct sections:

¨      XA - Tool Architecture

How the tool is fundamentally architected and engineered. Why? Because if that’s not done right, it will cause massive problems for all functionality and all users.

¨      XC - Tool Configuration & Maintenance

How the tool is Setup and administered by those people who are responsible for setting up all the reusable things such as meta-models, notations, standard viewpoints etc. that everyone else will use.

¨      XF - Tool Functionality

Key functionality that must be present if the tool is to be used for Enterprise Architecture.


XA - Tool Architecture X-Requirements

XA1. Single Object Table

There should be a single table of all objects (e.g. Objects, Elements or Components) with their type indicated via a foreign key to a unique list of types, as opposed to an individual table in the database for each object type (i.e. separate Process, Application, Department tables).


Because without a single table for each object type, the underlying repository is completely rigid, and the inevitable configuring of existing objects for additional attributes or adding of new objects altogether is going to require some serious back-end customization. Not to mention the consequent business logic and presentation layer hacks that will be required. In some cases “spare” tables are provided or attribute “slots” but this is hardly configurable.

XA2. 1st Order Relationships

All relationships between the objects in the repository should be explicitly stored as a different collection of elements in their own right, as opposed to being only on the diagrams, or attributes on objects, or just some specific subset of objects).


Because without modelling relationships as 1st order entities, a tool fails as a real architecture tool (see IEEE 1471). These sorts of convoluted designs smack of being a kludged together. Most likely, relationships on the diagrams were an afterthought to be stored in the repository with some serious implications including the next few criteria.

XA3. Heterogeneous Hierarchy

The repository should use a heterogeneous hierarchy of objects (and relationships), as opposed to flat collections of objects with (for example) a ‘decomposes’ relationship between them or only homogenous hierarchies.


Because with a single flat collection of each object (or relationship) type, none of the principles of information hiding and role-based access are available. Slightly better are approaches that allow homogenous hierarchies where at least objects can be decomposed natively into objects of the same type (e.g. Processes into sub-Processes). These approaches are legacy of ‘flatlanders’ who simply compose Meta-models as ‘boxes and lines’ without any use of heterogeneous composition/aggregation or ‘boxes within boxes’. Cars have four wheels, an engine, gearbox etc. … not just sub-Cars.

XA4. Foreign Keys Relations

The relationships between the objects / entities in the repository should be defined and stored in the repository, rather than defined and stored in program or SQL code.


Because if the relationships are stored in the program or SQL code, this creates serious limitations on what relationships can and cannot be defined and if you want to change them, you would have to change program or SQL code rather than just the data in the repository.

XA5. Plain Text Encoding

The objects / entities / tables and relationships in the repository should be coded as decipherable plain text data, as opposed to being binary objects from some other proprietary format.


Because the practice of “wrapping” a proprietary data model as binary objects or other coded data in order to become “SQL Server” or “Oracle” compliant severely reduces the openness of the customer’s data that is ultimately being stored there.

XA6. Time as a Fundamental

The repository should:

a)     Allow any objects / entities and any relationships to exist in time., rather than just having a “time” attribute attached to them

b)    Allow different versions of architectures / scenarios

c)     Allow for relationships to exist between architectures / scenarios, rather than just storing different scenarios as separate repositories that cannot be related.


Because EA Modelling tools are built to allow Enterprises to transform things over time. This mandates modelling the structure of the Enterprise at various points in time. It is therefore paramount to be able to model relationships between these different point-in-time models. If time has not been properly considered and designed in to the tool from the beginning (i.e. architected) you will face serious limitations when you come to create and maintain roadmaps and different scenarios - which, after all, is the whole point of an Enterprise Architecture.


XC - Tool Configuration and Maintenance X-Requirements

XC1. Bulk Upload

It should be possible for a user to bulk upload 1000’s of rows and columns of structured data to the repository in a single step from MS Excel, MS Access and/or MS SQL Server with the base product, as opposed to one-by-one copy-pasting data into forms or requiring professional services support.


Because users may well assume this to be the case and then be surprised by a large cost required to either enter data by hand or to pay for professional services to do the work.

XC2. Structured Upload

It should be possible to bulk upload objects, relations and attributes all at the same time, as opposed to a single flat collection of an individual object type and their attributes at a time.


Because, as POET teaches us, “The value is in the lines, not in the boxes”. If you can only upload lists of single entities at one time, there is very limited ability to easily build a connected repository.

XC3. Open ERD

Documentation of the complete Entity-Relationship-Diagram (ERD) / Object Model (OM) for the repository should be provided to clients on request, as opposed to being kept secret, and the relationships between the objects / entities / tables should be explicitly defined as relationships in the database technology being used, as opposed to being coded in application logic. It should be clear by looking at the datamodel utilised by the repository how all the tables are related.


Because if the datamodel (which may or may not include its relationships) is either non-existent or hidden, this profoundly inhibits users from running reports using other external tools of their own without requiring potentially costly professional services fees to achieve it.

XC4. Graphical Meta-Model

It should be possible to use a graphical and navigable representation of the Meta-model(s), as opposed to creating (and maintaining) a dummy set of entities based on that Meta-model or by editing cryptic configuration files.


Because understanding and maintaining the Meta-model(s) used, is crucial for the correct and streamlined management of an EA Modelling Tool. This can be highly complex, and attempting to do it purely by editing “configuration” text, is fraught with difficulty.

XC5. Hybrid Metamodels

It should be possible to concurrently utilise and relate multiple Meta-model implementations out-of-the-box.


Because the Meta-model(s) used by any Enterprise will generally be a mixture of Meta-models rather than just one. e.g. P3O + BPMN + Archimate + PEAF + BMM. Without this ability, you will find it extremely difficult to create “your” Meta-model(s) and even more difficult to utilise them effectively.

XC6. Flexible Notation

It should be possible to change the iconography of the Explorer / Object Browser and shapes used for the objects themselves on the diagrams, through simple drag-and-drop operations in the standard UI, as opposed to hacking code or some convoluted editing of a cryptic configuration file.


Because a lot of the frameworks don’t have agreed notations so it is essential that the appropriately trained / skilled users can easily reconfigure the look-and-feel of the views for maximum business impact without needing vendor support or ever writing a line of code of customization.

XC7. Tool Integration

The tool should provide the ability to seamlessly integrate with other tools, and be able to synchronise precisely with the data they contain, without any need for translation or transformation of their data, such that changes made in the EA Modelling tool are pushed out to other tools, and changes made in other tools are incorporated back into the EA Modelling tool, all in a controlled way and without any loss of data.


Because no tool exists in a void. The tools you choose must cooperate together into a coherent whole. If your EA Modelling Tool cannot integrate and synchronise faithfully and easily with data in other tools (without the need for any transformation of the data) all you will do is create another island of data, with all the risks and costs related to duplication of data, and those data becoming out of date and therefore useless.

XC8. Concerns & Viewpoints

In addition to the obvious requirement for a Metamodel (and the requirement for Hybrid Meta-models) an EA Modelling tool should also allow for the definition of:

a)     Users - Who will use the tool to answer questions?

b)    Concerns - What questions do those stakeholders require answers to?

c)     Viewpoints - How those questions are answered?


Because as POET teaches us “There is no reason to model anything unless it will be used to answer a question.” In order to do that in a reasonably coherent way, the tool also needs to define who wants the question answered, what are the questions that require an answer and how that question will be answered.


XF - Tool Functionality X-Requirements

XF1. Meta-Data Inheritance

It should be possible to define meta-data on a general entity in the repository, that can be inherited and then extended by local object or relationship instances, as opposed to simply having a relationship type called Generalizes or Generalized By (or Specializes / Specialized By or Realizes / Realized By etc) between two existing objects.


Because a lot of tools provide a ‘flat’ repository with tables of objects (and possibly foreign-key relationships between them). This approach ignores the concepts of inheritance and meta-data. Invariably these tools are then kludged to provide a specific relationship type called ‘Generalizes’ or ‘Realizes’ between two existing objects. This approach does not exploit the benefits of inheritance including efficiency, meta-data re-use and specialization.

XF2. Dangling Relationships

It should be possible to detach the end of a relationship from an object on a diagram and leave it unattached (i.e. ‘hanging in space’) and then re-attach the same end of the relationship to a different object.


Because if a tool merely has a drawing SDK on top of a RDB it is probable that only some of the drawing features are ‘linked’ to the RDB. For example, to allow there to be a detached relationship at some point in time on a diagram (as a minimum) the relationships need to be explicitly contained in the repository (not just an ‘attribute’ of the objects) and there needs to be tight coupling between the diagrams and the repository.

If a user cannot detach then re-attach relationships, when you inevitably want to change the attachments, the user will have to delete and recreate them, losing all the information associated with the relationship, and its occurrence in any other views.

XF3. Explorer Drag And Drop

It should be possible (using the “Explorer” or “Object Browser”) to re-order items in any way using simple drag-and-drop, as opposed to, for example, just a forced sorting of alphabetical ‘A-Z’ or ‘Z-A’.


Because there is often a logical ordering to the group of objects that isn’t alphabetical, e.g. Business - Information - Application - Technology. If the sorting is forced, then you end up prefixing all the objects with a numerical index to control the sort order.

XF4. Explicit Variants

It should be possible to explicitly model variants / scenarios / what-ifs / options etc as separate collections of (the same baseline) objects relationships and views, as opposed to just ‘tagging’ the one set of objects / relationships with flags saying which variant they are in.


Because just ‘tagging’ objects seriously limits the amount of difference / gap analysis that is possible, and more or less negates the ability to do trade-off analysis at all.

XF5. Analytic Charts

It should be possible for the tool to produce standard charts like pies, lines, bars etc.


Because if the tool can’t produce simple charts, it may struggle to produce other more complicated diagrams or analytics.

XF6. Quantitative Analytics

The tool should allow for quantitative ways of analysing the information in the repository, not only simple analytics such as “how many”, but more detailed analysis for KPIs from the Financial (e.g. Total Cost of Ownership (TCO), ROI, NPV) to the Technical (e.g. Resource Utilization, Response Times, Availabilities) to the Environmental (e.g. Carbon Footprint, Resource Re-use, Sustainability, Heat & Power Consumption).


Because the purpose of an EA Modelling tool is to model various Structural states of an Enterprise and to quantitatively analyse the differences between them, for the purposes of:

a)     Roadmapping - Analysing differences between states at different points in time - for the purpose of creating a roadmap to move from one state to another, and

b)    Options - Analysing differences between states at the same point in time - for the purpose of selecting which one is more appropriate.

XF7. Catalogue Data Management

It should be possible to manage a catalogue / list of elements (e.g. objects, entities, relationships) and their properties natively in the tool, as a tabular list of data through the standard UI, as opposed to hacking into or querying the back-end repository / database (assuming it’s possible to understand).


Because tabular data entry / management is fundamental to efficient portfolio management of data around objects / relations, and simply providing a single form / screen per object and relationship for data editing, is going to guarantee data obsolescence very quickly.

XF8. Round Trip Engineering

It should be possible to export information into Excel and Visio, allow someone to edit that data, and then reimport the changes they made back into the repository.


Because Excel and Visio are widely used applications that most people are familiar with and most Enterprises already own. To be able to lever this existing investment and to give people information in a format they are familiar with allows many more people to be involved with the creation, maintenance and consumption of the information in the repository.


Questions to ponder...

Do you agree with these high level X Requirements?

If not, which ones would you add, change, remove?

How would you weight them in terms of importance?

◄◄◄ Previous Page          

          Next Page ►►►


© 2008-2019 Pragmatic EA Ltd