How was Training?

more

“Positive experience in understanding this method of applying common sense to EA.” - Services Director, Venture 1 Consulting, UK, May 2013

Recommend PEAF?

more

“Yes - Easy to understand” - Consultant, Private, South Africa, Jan 2015














The following are provided as 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.

They are split into three distinct sections:

¨      XA - Tool Architecture

How the tool is fundamentally architected and engineered. This is important 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

XA1. Single Object Table

Description

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).

Rationale

With 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

Description

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).

Rationale

Without modelling relationships as 1st order entities a tool fails as a real architecture tool (a la IEEE 1471). These sorts of convoluted designs smack of being a kludged together Object-Oriented (OO) approach with objects being the only element of interest. 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

Description

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.

Rationale

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

Description

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.

Rationale

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

Description

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.

Rationale

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

Description

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 version of architectures / scenarios

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

Rationale

EA Modelling tools are built to allow Enterprises to transform things. This basically consists of modelling the structure of the Enterprise at various points in time. It is therefore paramount to be able to model relationships between these “different” 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 EA modelling tool.

XC - Tool Configuration and Maintenance

XC1. Bulk Upload

Description

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.

Rationale

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

Description

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.

Rationale

Based on the premise that “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

Description

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.

Rationale

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

Description

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.

Rationale

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

Description

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

Rationale

The Meta-model(s) used by any Enterprise will generally be a mixture of Meta-models, e.g. P3O + BPMN + Archimate + PEAF + BMM for example, rather than just one. 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

Description

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 other convoluted edit of a cryptic configuration file.

Rationale

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

Description

The tool should provide the ability to seamlessly integrate with other tools and to 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.

Rationale

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

Description

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?

Rationale

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

XF1. Meta-Data Inheritance

Description

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.

Rationale

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

Description

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.

Rationale

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

Description

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’.

Rationale

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

Description

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.

Rationale

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

Description

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

Rationale

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

XF6. Quantitative Analytics

Description

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).

Rationale

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, or

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

c)     Both of the above at the same time.

XF7. Catalogue Data Management

Description

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).

Rationale

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

Description

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.

Rationale

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.

 

◄◄◄ Previous Page          

          Next Page ►►►



 

© 2008-2016 Pragmatic EA Ltd