This blog has been written by Louw Labuschagne, an IT consultant with over 20 years of experience. To view the full White Paper, download it for free at: https://www.orbussoftware.com/resources/downloads/top-ten-factors-to-consider-when-selecting-a-togaf-9-repository
To establish a sustainable Enterprise Architecture Practice based on TOGAF 9 you need a solid architecture repository. When doing an internet search for Enterprise Architecture (EA) repository tools you can find everything, from open source ontology projects to master data management software being packaged as EA repositories, so finding a proper EA tool that will support your initiatives is not a trivial task. I have worked on a variety of EA projects using different tools to capture and manage the concepts, and the relationships between those concepts, that I require to produce useful information that I can package for different stakeholders.
Based on my own experience, and those of the architecture professionals that I have worked with and trained over the past 8 years, I believe the following 10 key factors must be considered before jumping into a licensing agreement. Furthermore, I don’t base my decision on which tool to buy just because the vendor tool is placed in a certain quadrant on a report by a research analyst.
Number 1: EA Repository
During my earlier years as a consultant I was exposed to a whole range of
products that could be very loosely defined as “architecture repositories”. I
grudgingly used these tools out of desperation, just to save my models in
a re-usable format whilst trying to convince the client or boss to invest in a
sustainable architecture repository. The standard answer I almost always got
was; “You have Visio installed on your laptop, what more do you need?”.
Well what I needed then and now, as a bare minimum, was to have my models shared with the rest of the team and the ability to re-use the models on multiple views and projects. After a while, as I started working on new projects, I only had one rule when asking the IT Department for a modeling tool; the tool must use a repository.
Soon after I made this rule I worked at an organization that provided IT outsourcing services to large clients, and after requesting a modeling environment with a single repository, I received a UML modeling tool linked to a Subversion Version Control Repository; not what I wanted, but that was what I asked for! I must admit, it did work and we did complete the project, but at most I can say we did not strictly follow the UML rules, leading to an unsustainable repository in the long run.
After the project I updated my rule: I now want to be able to access the data (or building blocks in TOGAF terminology) without being forced to use the modeling front-end. The benefit I find with this is that you have a self-contained, real repository with referential integrity (I prefer relation databases) and with the ability to extract data in different formats as the projects require without using predefined reports or viewpoints.
Number 2: Extending the meta-model
Starting my modeling career using a UML modeling tool and an inflexible repository, I soon became agitated with a tool that will not allow me to extend the basic model types to fit the requirement of the client (although the UML language is great for creating extensions). I had no choice, but to create a little instruction manual on how our project team interpreted the UML notation and how we used different colours to represent different building block types in the organization. If someone forgot to change the colour of a shape, we had data inconsistency!
The result was my second rule, the repository meta-model must be updatable by someone who does not necessarily hold an advanced degree in microprocessor design or quantum physics.
Number 3: User interface
I can honestly say that when I see the user interface designs, or Human Computer Interface (to use the correct term), of some of the larger Enterprise Systems, the average Architecture Repository vendor is not doing too badly. On average I find that an experienced modeller will
find them intuitive and of benefit, but the occasional modeller, Business Analyst or Senior Enterprise Architect will prefer not to break the rhythm of the experienced modellers by asking silly questions, so they continue to model in Visio and then print the models for the experienced (and more junior) modellers to recapture into their sophisticated modeling tool.
This way, everyone is productive and the timesheets are always filled with extra hours of modeling. However, this bliss only lasts until the project timelines start slipping, and the project managers start asking the difficult question of why he need to pay for two resources who are duplicating the same work (and of course the client also wants to know why the effort is duplicated; he prefers the Visio model because it looks pretty, so just stop re-doing the work!).
Rule number 3 states that any tool that I use on a project must be able to use Visio, import Visio diagrams and map it to my custom meta-model or visually look like Visio!
Number 4: TOGAF 9 support
You cannot just create random models. Well, if you have Visio the sky is the limit, so maybe you can just model, but the sustainability and re-use of the models will sometimes not even reach the end of the project. The biggest concern I have with Open Source software (and Visio) is that you only own a tool that will draw the shapes; there is no intelligence behind it or a methodology that gives it a purpose in life! The major tool vendors all ship with integrated modeling environments and a standard methodology that helps the modeller understand how and when to use the modeling shapes (my first exposure to this was with a German developed modeling tool, using a house as a starting point).
Enterprise Architecture projects are more difficult to tackle than Business Process Improvement or Solution design projects, where standards like BPMN, UML and Entity Relationship Models are standard notations with solid methodologies to support the modeling effort. The Open Group’s TOGAF 9 framework together with the new ArchiMate notation is an excellent starting point for any Architecture project. Using TOGAF to define enough governance controls, even Visio modellers can be allowed to roam free on a project. The TOGAF 9 Architecture Development Method allows me to define a set of Viewpoints at the start of the project, which I can confirm with stakeholders and distribute to the architects and modellers to create, with a predictable, consistent result at the end. If I now have a choice in selecting a tool, I always prefer (rule 4) to have TOGAF 9 support out of the box.
Number 5: Bulk Uploads of Data
My love for modeling lasted until I had to create over 700 applications objects by hand and then just over 300 process objects (not counting the manual linking I had to do to get any value out of the process). Sticking to rule 1, I had access to a repository (with a relational database management system), which allowed me to peek into the back-end of the tool. Within a few hours I had the key tables and attributes identified. By running scripts on the database I was able to import the rest of the building blocks in a fraction of the time it took to create the original set.
I tried a different strategy with my next assignment and e-mailed excel spread sheets with fixed columns and rows to stakeholders and, by using the data extraction script, uploaded and linked a large amount of building blocks in a very short time. When I now evaluate modeling tools, I also include rule number 5 – the Modeling tool must be able to import excel spread sheet data.
Number 6: Visualization of Views
I have spent a large amount of my time trying to get information into a repository, but with some tools it took me even longer just to generate a report or view that was presentable to non-technical stakeholders. Some tool vendors are building the modeling tools and repositories for architects and modellers but do not realize that a major beneficiary of the repository is the senior manager, who needs to make key decisions using information from the repository. Important information is often hidden to them by layers of inaccessible, obscure modeling notation and complicated report generation engines. I encountered this problem very early in my career, but am only now starting to see commercial vendors develop tools that are designed with the real end-user in mind. So, non- negotiable rule number 6 is: the views created from the repository must be visually impressive and easy to access.
Number 7: Data analysis
Number 8: Information Assurance
Nothing drains the energy out of a project or initiative as quickly as when stakeholders lose faith in the quality of the information being presented or by the process in which information is collected. Despite the fact that advanced architecture repositories are designed and implemented using cutting-edge technology, I have found that the information quality and the consistency of the repository must be reviewed on a regular basis by performing technical quality assurance (running internal consistency scripts in the repository).
Technical integrity tools and reporting must come standard with any good repository, so that is my rule number 8: ensure that the vendor and tool understands what is meant by technical integrity checking. Otherwise, run!
Unfortunately, the logical quality assurance is a human function and although I would have loved to embed an Artificial Intelligence module into the repository to do the checking, it is still a role that has to be performed by someone on the Enterprise Architecture team.
Number 9: Technical Support
Technical support for your repository infrastructure is critical. My simple rule 9 is therefore: pick technology that your internal support staffs are comfortable with, i.e. if you are using SQL Server and Windows Server in your data centre then pick a tool with those technology components. It just makes life much simpler during routine support and maintenance tasks.
Number 10: Vendor Support
The last point seems obvious, but buying software from a website or downloading “community edition” software will give you exactly the kind of support that you paid for... zero. Building your own repository is always an option; I had a successful SQL Server-based repository running for about a year before the novelty wore off and the D.I.Y. repository ended up in the store room with all the other novel ideas.
Maintaining and supporting an Enterprise Architecture Repository is a serious business and that is why I want to end with my rule number 10: get the professionals in.
Conclusions
In conclusion, I am not attempting to create an architecture tool comparison table, just because it is so subjective and because there are so many of those tables already available (and also if I excluded the list of business process management tools that charade as EA tools, then I might just get a backlash from the vendor community).
I do however think that when evaluating EA tools, practitioners should play close attention to the rules I have outlined in this document. If you have a tick in the box for all of the above you will have the best chance of creating a repository that is capable of delivering the business value you require from your EA efforts.