We wrote up a technical whitepaper that summarizes TOGAF and how you can build, maintain, and gain return on investment on an enterprise architecture with our tooling — System Architect, Focal Point, RAM, and other IBM tools.
The technical whitepaper – Building Enterprise Architectures with TOGAF 9 — is available for download for free, here: http://public.dhe.ibm.com/common/ssi/ecm/en/raw14241usen/RAW14241USEN.PDF
The DoDAF 2 specification is now mandated by the Department of Defense for new undertakings. We have all been working in DoDAF 1.5 for many years with System Architect supporting both variants of DoDAF 1.5 (Standard and Activity Based Modeling or ABM).
We all saw the change to the DoDAF 2 standard coming. Our customers in government, the A&D community and IBM have been participants in the DoDAF 2 Working Group since its beginnings and the change to the DoDAF 2 standard is not a surprise.
However, many of our customers have models in DoDAF 1.5 that they have been reusing across projects and initiatives for many years. Customers have improved and updated their models over time to incorporate new requirements and both operational and system advances. Reuse was a major objective of DoDAF and, judging by the demand for a migration to DoDAF 2 by our customers, that was accomplished. In fact, our customers are expecting to continue to reuse and advance their existing models in DoDAF2.
Despite the customer use differences and the conceptual and technical differences between DoDAF 1.5 and DoDAF2, an automated migration was needed. Our customers, both in the DoD and A&D, made it clear that they needed to continue making use of their existing model assets while complying with the Department of Defense directive to use DoDAF2.
I recently had a discussion on an internet radio chat about using the System Architect Migration Toolkit to migrate DoDAF 1.5 models to DoDAF2. You can listen to the chat here– the link should auto-send you to chat #206, Using the DoDAF 2 Migration Toolkit to Migrate Your DoDAF 1.5 Models to DoDAF 2.0.
If you have trouble listening on line, download the mp3 here. Get the brochure by clicking here.
Questions I’ve fielded at least several times in the past few years: a) “What is the ROI on enterprise architecture?”, and b) “Enterprise Architecture is overkill, isn’t it? You don’t really need it.” Here is my answer: Every organization already has an EA in place, whether you like it or not; whether you want it or not. Period. (Exclamation point!)
Now the questions back — how much do you want to know about your EA — that you already have, like it or not — and which is often completely screwed up, at least in some areas — so you can run your organization better — understand consequences of your actions before you make decisions; understand inefficiencies or redundancies or communication issues? How many duplicate applications do you have running across business units that serve the same purpose, and how much is it costing you to maintain those redundant or seldom-used applications? If you are about to spend money to introduce a new system, do you really need it, or are there existing systems already deployed that can do the job? If there are severe thunderstorms in a particular region of the country where one of your server farms is located, can they bring down your cloud? Are your workers banging their heads against the wall trying to get things done — constantly tracking down answers to process questions (ie, how to get something done in the organization — without having to send emails around all over the place)? How many inefficiencies exist at your organization that can be discovered by just a little bit of EA discovery work?
How valuable would it be to have such information at your fingertips?
You want ROI numbers? Here’s are some ROI numbers — an article in Computerworld highlighting some of the work done by our colleagues internally at IBM — in this case around application portfolio management: http://www.computerworld.com/s/article/9226430/IBM_on_path_to_cut_internal_apps_by_85_
I’m working with the CEO of an internet company, helping him build an architecture for a new line of business. He’s gotten real value from System Architect in a number of areas. First, his developers, who are in India, have reduced their code cycle by at least half because the design of the software is documented in System Architect and they understand exactly what is needed (the design is done in UML). Second, he mapped out his strategy for integrating off the shelf software for his new project using the System Architecture diagram which has helped vendors understand his requirements. Third, he has mapped out the business functionality and processes for his new line of business using IDEF0 and BPMN so that he can better plan the start up and understand what needs to be in place when.
And yesterday he came up with a new use for his architecture.
He’s been working with software vendors to figure out how their software will integrate with other vendor software he’s using. Unfortunately, in the past he’s had to meet with sales people before he could get a meeting with the engineers to get answers to his technical questions. That’s a waste of his time. He also had a hard time getting some vendors to take him seriously because he’s a small company.
But he noticed in a meeting last week that as soon as he pulled out an IDEF0 diagram the sales guy was like “um, let me get an engineer to help you”. So he asked me to come up with another diagram that would “scare the sales people away” but allow him to communicate the technical aspects of his design to the engineers.
We decided to use a UML sequence diagram and he said his meeting this morning with the engineers of a vendor he’s working with was very successful. The engineers were able to confirm that his design was feasible using just out of the box features of their software. I also showed him how to generate a web site using the out of the box HTML generator in System Architect. He said it makes his company look “more impressive” and that the vendors he was meeting with liked how easy it was to navigate and understand his design. For example, if they don’t understand what a message flow name means they can easily look up the definition. We also included actual examples of data as well as timing requirements in the definitions.
Two good reasons to do EA in System Architect – to intimidate and impress people.
The other day in a hotel room I happened on the show Iron Chef. A friend of mine who’s still convinced that I can learn to cook, even after numerous kitchen disasters, had recommended I watch the show.
For those not familiar, top chefs work with up and coming chefs in a timed contest to create a dinner that the judges then vote on. The participants don’t know until the show starts what ingredients they will have to use in their dishes.
The show has additional complexities but I have to admit I stopped paying attention because it suddenly struck me as a good idea to have an Iron Architect contest. There would be three judges and the participants would get 10 requirements that would have to be addressed in the architectures they develop. The participants would have 8 hours to develop a comprehensive architecture. Each participant would have an Iron Architect to help them, but it would be in an oversight and mentoring role. The iron architect would not create any actual architecture.
Cooking is a lot like architecture. It’s subjective (some people like eating cow hearts – but even if they are considered a delicacy I would never eat a cow heart). Some people cook using exact measurements while some just wing it. In architecture some people use industry standards and other just make stuff up. The title chef, like the title architect, can apply to anyone regardless of their skill or training.
It would be nice to see people improving their architecting skills, and for other architects, especially new architects, to see how an expert works.
And the contest would be much more exciting than a boring technical session…
I have been involved with modeling and modeling tools for a long time, dating back to the CASE tool days. My mentor from the beginning of my career, when teaching me the notion of modeling and what it was used for, once said: “the primary purpose of any model is to communicate”. In those days, but for a few very specialized tools, most modeling tools took the approach of simply automating a process of building diagrammatic depictions, replacing what people were currently doing by hand. Communication was achieved because the user used a standard method and the tool automated the process of building a model according to that specification (graphic standards and meta-model) and presented it in an easily readable way.
As time moved on and concepts such as TQM, BPR, and much later EA became something people were interested in using modeling tools for, the simple capture and rendering of model data was no longer sufficient. People began to want to use their model data – the fruits of all their hard work – for something besides just printing in documents or presenting in PowerPoint slides.
Data Must Be Complete for Analysis to Work
One of the first areas I was involved in was building a tool for using activity models as the basis for Activity Based Costing; shortly after that another project focused on using process models as the basis for process simulations. In both of these cases, this involved the use of the model data to analyze the part of the enterprise that particular model represented. And in both these cases, and the many cases since, the one fact that that is always true is what every programmer learns in year 1 of college – garbage in, garbage out. The data used for these analyses must be complete for the analysis to work – unfortunately often the only way to check for completeness was to either build reports and check via reading the report looking for blanks, or attempt to run the desired analysis then trouble shoot why it failed.
Of course, the worst case scenario is if the analysis runs and appears to work…but does so using incomplete data…possibly resulting in a decision based on that flawed analysis!
Over the decades since, the names of the practices around which models find use have changed, as have the methods (such as the introduction of Object Oriented methods) and frameworks. Additionally, many of the modeling tools have come and gone, though notably System Architect has been flexible and powerful enough to evolve as times have changed. One thing that has remained consistent however is that people have a desire to use their data for something more than a nice printout – often the words they use to describe their desired use are “analysis” and “decision support”.
DoDAF 2.0
By way of example, DoDAF 2 – Volume 1 specifically discusses the use of EA data and states “Architecture-based analytics includes all of the processes that transform architectural data into useful information in support of the decision making process.“
Volume 1 goes on to discuss, in section 10.5, the “Principles of Architecture Analytics” and states that the “five key foundational principles of architecture analytics are”:
1) Information Consistency
Dealing with data being collected in accordance to an overarching metadata structure; e.g., meta-model.
2) Data Completeness
Which refers to “the requirement that all required attributes of data elements are specified”; and continues on to mention examples of why this is important for architecture based analytics and decision support.
3) Transformation
4) Iteration
5) Lack of Ambiguity
Lou has done a great job of discussing meta-models and System Architect in previous articles and Martin has introduced another meta-model for consideration in Archimate for System Architect. For the purposes of this article I am going to focus on item 2 on the list. Why? Because, regardless of the meta-model involved (DoDAF2, Archimate, UML, etc.), and regardless of the name given to the practice in which various models are used (EA, BPR, etc.), or even the tool used – the one thing that is absolutely necessary for the collected model data to be of any use beyond a graphical depiction is that the data be complete enough to serve the intended purpose.
‘Required’ Properties
Those of you familiar enough with the properties language of System Architect are aware that there is the ability to make any given property “Required” – and certainly thoughtful use of that capability can go a long way toward ensuring that the resulting architecture is complete enough for the stated purpose. However, it is often true that the data collected in an architecture, and how it is collected, is not such that you want to prevent the entry of an item if the user does not have all the required attributes at the time of creation, as will happen with the “Required” keyword. And of course, many larger EA projects involve more than one team member so there will be varying levels of knowledge of the subject matter and thus necessary follow-up research. Also, it is not likely any single person will have knowledge of “how far along are we” – though certainly that question will arise.
It is for these reasons – the real word way data is collected and the requirement that the data is complete for any analysis of that data to be valid – that EA Frameworks has created a macro add-on to System Architect for the specific purpose of analyzing the completeness of the data contained in the encyclopedia. The macro allows the user to specify the “required” properties of a definition type (“required” properties are certain to change based on the intended use [purpose] of that definition in analysis) and then queries the content of the encyclopedia to determine the level (percent) of completion of the definitions. The result of this macro is presented in several ways:
1) Charts in Excel that show percent complete for each property
2) Sheets in Excel that show the definitions with “blank” properties and what the properties are.
Performer Dashboard — Click to Enlarge.
The results of the macro can be used for several purposes:
And others I am sure.
Not to oversell the idea – completeness and correctness are related but separate concepts. Just because a value exists in a property does not mean it is meaningful or correct. Also related is consistency – for instance, what is the answer to the question “Is the total set of data and stated relationships internally consistent such that one part of the EA is not in disagreement with another part?” These other concepts will serve as the basis for both future articles and upgrades to the metrics macro for System Architect.
That said, completeness checking is an important but often overlooked check of any set of EA data. This macro is intended to make that check as simple as possible.
For a running (shockwave) demo of the metrics macro please go to:
http://www.eaframeworks.com/onprandaddes.html
Where you can see this and other macro add-ons for System Architect.
We at Corso are seeing many EA practitioners gravitating to the ArchiMate framework as the tool for delivering Enterprise Architecture. Why is this? Unlike many frameworks to date that do not specify how model views are represented, ArchiMate provides a clear notation and language for the communication of EA.
The ArchiMate framework is currently at version 1, owned by the Open Group (who also own TOGAF), and has some limitations, which we see are already being addressed in version 2. These limitations include a lack of mappings to technical reference architectures, the lack of BPMN views, and the lack of provision of other industry specific frameworks such as eTom. Corso have addressed many of these issues in its System Architect release of ArchiMate.
ArchiMate is rapidly gaining momentum, especially in Europe. We expect to see a clear convergence between ArchiMate and TOGAF over the next 2 years, now that they are effectively from the same stable. Much like BPMN becoming the defacto standard for representation of business processes (based on the fact that it provided a common notation), we expect ArchiMate to have the same impact on EA.
Join us for a Webinar on Thursday, November 10, 2011 at 3:30pm to 4:30pm GMT — An overview of the new ArchiMate extension for IBM Rational System Architect. Space is limited — reserve your seat now by clicking here.
If you cannot attend the webinar but are interested in our ArchiMate data sheet, please register at corso.co.uk, or if you require a coversation personally, call +44 (0) 1926 333222.
I just need to know the metamodel.
That is a common request from users for the variety of metamodels deployed out of the box with System Architect. What is your DIV-1 and DIV-2 for DoDAF 2? What is your metamodel for TOGAF 9? What is your metamodel mapping for your SA-DOORS integration? Here’s one that I’ve had recently – what is the metamodel mapping of System Architect to Focal Point (to bring the architecture into that tool for decision analysis)? At its basic level, Focal Point has Workspaces, Modules, Attributes, Views, and Elements; System Architect has Encyclopedias, Workspaces, Diagrams, Definitions, and Symbols. How do the two relate?
Be Sure You’re Talking On the Same Metamodel Level
There are various levels of metamodels and its important to make sure you are speaking at the right level. For example, although System Architect’s tool metamodel can be thought of as Encyclopedias, Workspaces, Diagrams, Definitions, and Symbols, those are just vehicles to represent the metamodel of the framework you use to capture data – definitions and their properties (or attributes), and relationships between definitions. For example, in TOGAF, to model that a Business Process is performed by an Application that resides on a Server at a Location, you can take a look at that metamodel – specifically that a Process has a many-to-many relationship to an Application Component (of Physical type) that has a many-to-many relationship to a Technology Component (of Physical type) that has a many-to-many relationship to a Location. What’s more, the relationships have names, and there may be more than one relationship between two elements.
Metamodel Me This Batman
Architects speak in metamodel language. Ask an enterprise architect to customize the metamodel to capture information specific to an organization, the first thing they do is build a logical entity relation diagram. The most important feature of an architecture tool is customization of that metamodel, to the depth and breadth necessary to capture information about the organization when harvesting it from various sources of record, whether that be importing an Excel spreadsheet of IT assets or applications, using a tool like Tivoli to sniff the network, importing documents of requirements or strategic intent information, etc. Customization means not just addition of a few attributes to an existing definition, but ability to add new definition types, new hierarchies of information, new relationships, constraints on relationships, new diagram types even. This is where System Architect sings above all other products in the industry and why it has been so successful for enterprise architects. It addresses this most core need of architects better than any tool on the market.
The Answer
The answer to the question you might have formed in your mind when reading the first paragraph, by the way, is that a DIV-1 is DoDAF 2’s abbreviation for Data Information Viewpoint number 1 – the conceptual data model, and DIV number 2 – the logical data model. With DoDAF 2 in System Architect, we support the DoDAF 2 metamodel directly in the tool; no mapping. So if you go to the DoDAF 2 journal and view the DoDAF 2.01 metamodel, and then view ours, you’ll see essentially the same thing.
DoDAF 2.0 Metamodel for Activities as Implemented in System Architect
Our development team (kudos to Mark Gregory and Ian Hancock) used System Architect’s new GUI for building metamodels in the tool, to build out the DoDAF 2 metamodel in System Architect, and then generated the “SAPROPS” code for that metamodel. They used Explorer diagrams to visually represent that metamodel in a kind of Entity Relationship view, and we published that in our help. We’ve had several customers thank us for this. Because for years they’ve been telling us, “I just need to know the metamodel.” The encyclopedia is available for download and viewing here.
I will reveal to you the SA-Focal Point high-level metamodel mapping in an upcoming blog post. Stay tuned!
You can look at the world around us as categorized into three kinds of relationships – Explicit, Implicit, and Inferred.
An explicit relationship is one that carries data on the relationship itself – the ‘join’ relationship. So for example, a marriage between two people carries information about the anniversary date, and the names of the people involved. In the modeling world, for those of you who are familiar with a CRUD matrix – the matrix you use to understand if a business process Creates, Reads, Updates, or Deletes a table in a database – it has a ‘join’ definition that carries this data. In System Architect, we have always referred to these kinds of matrices as ‘text in cell’ matricies, because you can put information (not only text, but lists of other definitions, so it is a bit of a misnomer) into the cell. In DoDAF 1.5 ABM, there are ‘triplets’ formed on both the operational and systems side – you specify the Role(s) that perform an Activity at an Operational Node in the OpNodeActivity ‘join’ definition (and respective matrix), and similarly on the systems side, you specify the System (Entities) that perform(s) a System Function on a System Node in the SysNodeFunction ‘join’ definition (and respective matrix).
An implicit relationship is a simple list. Sometimes you don’t care to capture information in the relationship – it goes beyond the scope of what you need to model in an architecture and makes building and maintaining the architecture tedious. A real-world example of an implicit relationship is Twitter. If you have a Twitter account, you know that you have a list of followers (and a list of people that you are following). That’s the only thing being captured about the relationship – the simple fact that you have a list of followers. In System Architect ‘parlance’ this is a property that is a ListOf other definitions, or a property that is a OneOf other definitions.
An inferred is the old six degrees of separation ‘hopping’ – if x is related to y is related to z, then x is related to z (through y). Clint Eastwood is related to John Wayne because they both played in movies directed by Don Siegel. In System Architect, you use the reporting engine to run SQL-like queries to get at this information and generate reports to publish it. Over the last six or so years, you’ve had the Explorer diagram to visually show the ‘cause-effect’ relationships – so you can run an ‘Explorer relationship report’ to visually show a direct relationship between, say, a Server and Capabilities it provides, if you run a report that goes from Capability to Activity to Application to Server. You can skip (or hop) the intermediary definitions if you want to visualize the ‘end game’.
Now, in System Architect 11.4, you can automatically visualize all of these relationships on any diagram type. Functionality has been added to the saprops/usrprops metamodel language that enables you to specify that a relationship is Explicit or Implicit – instructing it to draw itself between two symbols on a diagram if the underlying definitions are related in such a fashion. You can now also run ‘Explorer relationship reports’ on any diagram type (not just Explorer diagrams) to visualize ‘inferred’ relationships between definitions.
I can see the question forming in your mind – what relationships then, should be explicit, and what relationships should be implicit in an architecture? The subject of another blog.
As discussed in a previous blog entry (Don’t do it fast, do it right) the agility imperative for modern enterprises is not only to change fast, but rather to enable the right changes at the right time in the right way. This raises the natural question of how? How to identify the right changes, how to find the optimal time for implementing them and finally how to executive change in the right way?
Plenty of literature addresses these three questions – only depending on viewpoint (BPM, Enterprise Architecture, Business Architecture, software engineering etc.) a particular paper or book has different answers … What this illustrates is that different people have different objectives and different opinions on what constitutes the right changes – typically based on the discipline within which these people have grown and gained experience.
How do we overcome the tribal nature of a complex organization and evolve to a nation, working together towards common goals based on each our specialties and skills? In particular as in many cases these different “tribes” of the enterprise do not even share a common language base, do not have the same concepts as a foundation for understanding? The first thing to do is establish a common and recognized landscape for change; only then can we discuss how to collaborate and govern within that landscape. The landscape analogy is chosen on purpose as I believe that the first pre-requisite for building a nation is to map and understand the various tribes living within the borders of that future nation – once we know who is out there, maybe even understand some of their languages and goals, then our fears and concerns are immediately reduced, our challenges more tractable. We have in fact progressed from an unknown void full of dangers to an explored and known landscape – admittedly still with many challenges ahead, only now these are challenges that we can identify and address, as opposed to (often irrational) simply fearing the unknown.
I am of course not suggesting that a modern enterprise is exactly the same as a tribal environment full of fears and superstitions. Still the analogy holds in that something known and recognized is much easier to address than something unknown and not recognized. A prime example of this is that once BPM and EA practitioners recognize the need to work together for better business outcomes, then it becomes much easier to set up appropriate collaboration patterns for guiding and governing change.
