The perpetual question for enterprise architects is, which is the best enterprise architecture management tool. I have my favourite based on the past years experience, which I selected after a careful analysis of potential candidates. One of my clients requested a comparison between two tools and I would share the results here. Shortly the two tools are SAMU from Atoll and EA from Sparx. The summary of the comparison is, that they have to exchange the name they have! SAMU (System Architecture Management Utility) is a real enterprise architecture management tool, with all necessary aspects, while EA (Enterprise Architect) is a great system design tool, with very limited capability to be extend to enterprise wide repository.
Requirements analysed
The two solutions was analysed based on predefined requirements. In the course of the analysis they were been analysed based on their enterprise architecture management relevant capabilities only, although they have great extra capabilities not important for us here.
Each aspect got a description of the analysis and a score from 1-5. Score 1 means that the tool is inappropriate for the given aspect or the function is missing completely. Score 5 means, that the tool 100% fits for the requirements or rather gives unexpected but still useful extras.
The analysis is based on real experiences, means both tool was used to solve exercise about the requirements. In addition, the certain way also considered: reading the available documentations about them.
End-to-end enterprise architecture repository
The role of the architecture repository is to handle the entire Enterprise Architecture related information, which covers by TOGAF (The Open Group Architecture Framework):
- Business architecture (processes, organisation, actors, roles)
- Information systems architecture (applications, functions, implementation components, services, dependencies)
- Technology architecture, by other words the infrastructure (servers, networks, machine rooms, security zones, infrastructure softwares)
- The dependencies and relations between all entities of the layers above
Beyond the topics above it is worthwhile to handle the architecture changes, the architecture related decisions too, which allows to have each and every architecture related information in one single place.
One more thing to go for is, that each information has to be handled on time series that makes every past stages accessible.
Client specific data model
The effective architecture repository has to be built on a good meta-model. The model elements, I mean the object types, its attributes and the relations between them is changing from time to time, as the repository and the architecture management practices faces with new challenges. That mean, that the tool you use has to be capable to serve model changes, or customisation.
Concurrent use of the repository
Either the most important capability of the architecture repository is that anyone who needs information from it can get the appropriate access, including the simple reader user to the modifiers. It is a must that all users should see each changes immediately and trustworthily.
Planning on repository basis
The only way to build correct and precise architecture plans if they are build on an up-to-date and complete repository. On the other hand it means, that the plans have to be the axiomatic part of the repository! It will not happen anymore that one plan misses the other, two plans will be inconsistent to each other or plans refers the same architecture element on different name. The additional earning is that all projects can count on its live environment as the overlapping plans consider the others.
Rights management
Since the repository covers the entire Enterprise Architecture, it is necessary to control the access rights of the users to the different data domains. It may mean the control of accessing object types, object instances or attributes of object types or instances.
User interface
The user interface has to be intuitive and ergonomic, means that it has to be clean of unnecessary information and controls using a given function of the tool.
The speed of the UI is also an important aspect: the slow UI makes the tool unusable.
Interfacing capabilities
The architecture repository should not be a standalone solution! It is a usual requirement to integrate it with existing infrastructure inventories (CMDBs), user databases, network inventories or monitoring solutions, making the architecture information alive finally.
The information collected through these kind of interface will be utilised immediately and on the other hand, the live use of data will point to the potential lack of information or inaccuracy.
The comparison
EA
Opposing to its missleading name, EA is more a software design and modelling tool, than a proper solution for comprehensive enterprise architecture repository.
The Sparx EA is primarily an UML (and other standards) supporter planning software, which is great to prepare plans and documnetation based on these standards. These documents describes well the functions of a given application from one-two important aspects.The tool is capable to store the collected information, the entities of UML, BPMN, etc. in a central database, which theoretically opens the opportunity to support team-working and to handling software documentations in their interdependencies. The „theoretical” statement is relevant because the central repository database is rather an opportunity, since EA has no effective toolset to constrain the use of the information there.
In addition the models supported are some cases with their sophisticated details, while some other cases with the missing details result, that the information about a real-life situation is so hard to manage. Beyond of this changing, extending the predefined models is very hard and limited.
If we would "keep together" a simple application catalogue in EA, then it requires very precise and ordered use, which practically is almost impossible either for experienced IT professionals.
EA follows the approach of catalogisation of plans, which is rateher the way of "pasteboard" era, while the plans designed can simply skip or override any details the repository content. A little exaggeration is that EA is an Intelligent "Visio", which precisely represents the elements of the standards it supports, constrains the use of the model entities, with very low adoption capabilities.
What EA is really great for is design and document the internal details of an application (use case, class diagram, sequence diagram, process diagram), by other words to support application development. In addition it is good process (BPMN) and decision matrix (DMN) simulation.
Primary users are solution architects (please read: Architect roles and responsibilities).
End-to-end enterprise architecture repository
The result of the usable data models and the operation logic of EA the tool is convenient for end-to-end enterprise architecture repository role. The baseline of plans is the project, handling of each plans and the recorded entities happens inside that. The data sharing between projects is difficult with painful limitations.
The main focus of the tool is the application architecture out of the four defined above. It does not mean that there are no functions to define data models, organisations or infrastructure elements but they behave like an additional shell on the core.
The time serial based version handling of the object is not solved. Version handling is implied from the „pasteboard“ approach: it is possible to commit given momentums of plans into external version handling solution.
EA is not suitable to handle either changes (change as defined by TOGAF ADM) nor decisions, or to support decision mechanisms.
Evaluation score: 2
Client specific data model
EA uses wide range of predefined standard models, which are primarily design to handle the internal architecture of applications and the implementation details of them. The end-to-end enterprise modelling is hard to handle having strict restrictions. Here we have to highlight, that "models" here are nothing more but so called "stereotypes", which controls the graphical outlook of the objects and has some control on the type of lines - the relations - between them (In addition this control is usually switched off by the users to use one single type of relation only! Not centrally, not in the meta-model, per client instances, the user can switch this on or off...). The data sheet is identically the same for all type of objects by default! There is no reference to other object instances, no object type specific attributes! Only objects with the same fields to use (free text may contain any details...).
Evaluation score: 1
Concurrent use of the repository
EA has two different UIs, which allows parallel access, while the basic mode of operation is a local standalone installation. One of UIs is a web-based thin client, which is capable only to view the data (still with some limitations, like some entries will not be displayed while it looks the same as others in the repo). The web UI requires the server behind installation. The other client is the thick UI, which can also be used for data modifications (web UI has no capability for data change).
Working on the same plans in parallel frequently causes unstable client states, which finally requires restart of the client.
Evaluation score: 4
Planning on repository basis
Planning on repository basis has weak support in the tool. It is possible to include repository entries in plans with their all attributes and relations. The only problem with the approach is, that all also means those information which is irrelevant for the given plans, making them too complicated.
There are no function to help identified existing element, which drives user to redefine them. The capability of filtering for duplications is completely missing.
Evaluation score: 2
Rights management
The user rights handling focuses on projects, the access rights setup is limited to this field. The predefined user roles are describing generic application functionalities like Update Diagrams, Spell Check, Run Scripts, etc. There is no way to define personalised roles.
Evaluation score: 1
User interface
There are fundamental differences between the two kind of user interfaces. The web UI cannot display everything and it is not possible to manipulate data there, while it is properly fast.
At the same time the starting the thick client is super slow, all the interactions has long response times, the client frequently freezes. The most part of the screen is covered by irrelevant tools, buttons, information panels and the working board is very small. Finally, working on large plans is so difficult and painful.
Evaluation score: 1
Interfacing capabilities
EA has it own factory-built interface set, which are ready to use just after the installation, but they cannot be modified. In some cases the interface capabilities are limited, significant details of plans, object are missing.
Evaluation score: 3
SAMU
In the course of evaluating SAMU, the tool and an accessible data model configured into SAMU was analysed together. This statement has to reasons to highlight: first, SAMU arrives empty, with no data model at all, while it is possible to configure any kind of model you need; second, EA was also evaluated with data models. The model, which is used in SAMU for the evaluation is a wide range model applicable to handle the 360 degree view of enterprise architecture and its backbone is the TMF SID (Telemanagement Forum Shared Information/Data) data model.
SAMU (System Architecture Management Utility) like EA, fulfill opposing roles as its name suggest, since it is mainly an end-to-end enterprise repository. It is designed to show a not so complicated model about an enterprise (model means meta-model, which is flexible and configurable). The low complexity on presentation allows to show different understandable aspects to the different stakeholders about the IT and business resources types and their dependencies. While the model seems simple for the stakeholders it can be so sophisticated in the back. By other words the sensible complexity is low, while the E2E model is complex in the back. The users can be business people, management (either on CxO level), IT experts, developers, O&M people, enterprise security, external partners and so.
The repository is based on a well structured central database therefore it is possible SAMU to become an authentic central enterprise repository. It can handle applications, servers, interface and others. SAMU is by design a multi user, web-based solution which smartly support team working. The model is configurable without restraint, so the local client needs can be simply served.
The presentation of data happens through object type specific form and reports. Reports are the way of presenting plans; the reports are presenting a defined set of data (through database selections!), and they can be graphical drawings, table or either document based, where the documents can also contain the drawings.
SAMU has different APIs, which helps it to integrate into the corporate processes, becoming the organic part of the daily operation. Some example: change management, monitoring interface, interacting project portfolio solution or to interface with HR systems (when an employee leaves the company, his/her responsibilities must be covered).
The primary users are domain and enterprise architects (please read: Architect roles and responsibilities).
End-to-end enterprise architecture repository
The main target of this tool to serve the enterprise architecture repository role. The flexible data model and freedom of configuring UI either to build new screens using the report builder makes SAMU capable to implement either the change management or the entire flow of decision making process about the architecture. The SID based model used in the course of comparison also includes both the change management and decision support.
Every data is stored on time series, means each and every changes in the model, object instances, reports has its effective and expiration dates, and all the historical data is accessible using the „time machine“ function.
Time machine means, that a given time can be set in the past, and then all UIs, database selection and reports show that state of the repository what was the actual at that time. In time machine mode no changes are possible to keep the data consistency in time.
SAMU is capable to handle BMPN and DMN standard to manage process flows and decision matrixes.
Evaluation score: 5
Client specific data model
The evaluation covered a practical example, which included applications (logical resources by SID), application functions (RFSSs by SID), interfaces, and the service delivered to the client’s market (CFSSs by SID), processes, implementation components, networks, servers and so.
The model can be modified by any users having the proper administrative rights, without involving the vendor of SAMU. The model can be change parallel to the daily operation, since the tool properly manages the user relevant aspects of model change.
The model can have further changes as needed.
Evaluation score: 5
Concurrent use of the repository
Since the handling of data is based on particular object instances (instead of plans, projects as collection of data), it is possible to have read and write accesses to the entire repository independently for each users. The parallel data changes on the same objects handled by system, while changes on independent object has no any limitation.
The data manipulation happens on object type specific data forms, which is the same for all screens where the manipulations can be initiated: lists, drawings or search filters.
Evaluation score: 5
Planning on repository basis
Planning usually happens using graphical reports (plans). It is possible to include any kind of objects instance to a plan if it fits to the conditions of the report. SAMU has a search UI for this function, which filter on the instance of the object types fits to the given report (like applications or servers). It is also possible to create new instance for the case if the necessary entity does not exist in the repository.
The reports have to kind of conditions:
- which kind of object types it handle (application, server, process, function and relations between them)
- which instances of the types above should be displayed, what is defined the selection feeds the report.
A reports allow to create new instance only of those object types which with to the first criterion, while we can include an existing instance of an object type fits to the 1st criterion but does not fit the to the second. For example: we have a report display a project relevant applications, their functional modules and their interface connections. If we include an application, which is not relevant to the project it still will be shown on the plan, but with an indication that it is an outsider, and included with manual overriding. These elements will not be presented on other lists and reports which are relevant to the given project.
A similar case can happen, if we would create a relation between two entities on a plan. SAMU will show a pop-up, which suggest the usable connection types between the two entries and also shows and already existing connections, which are not display by the given plans, since they does not fit the 2nd condition above. This helps to avoid having duplications in the repository.
Evaluation score: 5
Rights management
SAMU has smart rights management capability. it is possible to create and maintain any kind of user roles by defining:
- which functions of SAMU are accessible
- which object types can be viewed or modified
- which instances of object types can be viewed or modified
- which attributes of object types can be viewed or modified
- which selection and reports can be used
A user can have multiple roles and the union of the rights defined in its roles is accessible to the user.
The user rights management has a limitation: very sophisticated rights definition slows down the system. An example: it is possible to define, that the common users cannot see the changes planned in a sensitive project. The solution requires to define a database selection which list all the items a related to the sensitive project and would not be access by the normal users. This approach, which requires large number of database operations each time is possible to use, but the right evaluation will be slow, therefore the operation slows down for the common users, since the listed information has to hidden only to them.
Evaluation score: 4
User interface
The user interface is a clear and simple web based solution. The screens are designed to ensure the largest possible area for the actual function used. The only disadvantage of the UI, which is on the other hand a great advantage, that each and every object type uses similar forms to display and maintain their data. The object type is display in the form header, while the form contains the object type relevant attributes in the order they defined in the data model.
For those attributes which are a relation to other object instances, instant search field is displayed to fast access to repository elements. The approach ensures the use of existing data instead of lead the user to the wrong direction, by adding free texts or creating new entities in the database. In the case when still a new object instance has to be created, the object type relevant form is opened on the top of previous one, which collect all the necessary data of the new object instance to create.
The user interface can be extended by new screens, through the special report capability of SAMU (xslt and javascript to display database content, validate fields, preload special forms, etc.).
The following picture shows multilingual start page defined to the current evaluation, which contains graphical web buttons to simplify access of the most common data and reports. It contains user specific content based on the user logged in to the system. The screen is implemented by end-user capabilities, using SAMU functions without vendor participation.
Important to highlight he wide range of capabilities of the visual reports:
- Each entities displayed there can have its on visual representation
- objects on the report can be ordered manually or by many predefined ordering algorithms, which can handle the objects and the lines separately
- the graphical elements can be labeled by additional layer definitions (like something will be retired by a plan, can have a red label on the drawing)
- SAMU has hundreds of vector-graphical drawing element out of the box, while the user can define anything new
- and so on, and so on. It could be a separate article to describe all of the visualisation capabilities.
Evaluation score: 5
Interfacing capabilities
SAMU has many different type of interfaces. The first to mention is a real IT kind one, called XML API. This interface can be used to export data into XML file, which will contain the all the request object instances, with the requested attributes in the proper hierarchy defined in the object meta model. The export can also refer to predefined (means the user can create without the vendor) database selections.
This interface is also capable to import XML based data into the repository.
For mass loading into the repository it is also possible to use the Excel loader wizard interface, which helps to identify the data in the source Excel, then validates the data, highlights the changes will happen in case of load, and if the user confirms the change, it load the content into the repository.
Beyond of the XML based export it is possible to export lists from the screens into Excel, also to define list type reports, which can be exported into css or Excel. The diagrams (visual plans) can be exported into many different vector and pixel type of image formats.
The special report capability allows to define anything, which is possible based on XSLT and javascript languages.
Although almost anything can be imported and exported by configuring the tool the number of predefined interfaces is low.
Evaluation score: 4
The summary of the evaluation
As the following table shows, SAMU is much better to build an enterprise architecture repository, although the name of EA suggests it is designed for this role.
Additional background information
Gartner
Gartner website has a great evaluation and many relevant peer review about both tools. It is interesting to read the comments about them, which confirms the result of this evaluation, either the ratio of the scores are not the same scale there.
Good to read the comparison of the tools too, which does not show the same large difference, since they used different evaluation criterion, but the result is so similar. Gartner give score 1 for that case, when a given function is missing or defective. In the current evaluation there was no case like that, but the score 1 here at Architect Archers meant the solution is inappropriate or the functionality is poor for the current requirement. Again, the difference between the score is not that significant at Gartner, but the „Willingness to recommend” value is suggestive!
Pragmatic EA
The CEO and lead analyst of Pragmatic EA, Kevin Smith prepared an exceptional analysis of the landscape of architecture management related tools.
Good to know about the analysis, that the main source was questionnaires since it is impossible to compare that large amount of tools in practice, collect equivalent experiences about all — not to mention getting every licences necessary for the evaluation. Opposing to Pragmatic EA evaluation, our analysis picked only two software, but went into the practical details solving real-life problem with both.
The analysis summary in a book, which can be readable online here.
The summary of SAMU is on page 60., EA is on page 88. Interesting to read the aspects of the analysis from page 91 and the summary of the final result at page 104-105.
By my experiences some of the all-green solutions at Pragmatic EA are really great, but focuses most to the point of view of the top management, and less capable to serve the low level details in parallel as SAMU can.