Modified on by LouV
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”.
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.
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.
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:
- Compliance/conformance checking – if standards exist for collection of EA data such that there are completeness requirements, this macro can save a great deal of time that would otherwise be spent looking for blanks in reports.
- Pre-analysis completeness checks – as mentioned above
- Tool bridge analysis – for instance, does the data necessary to generate complete code or output a complete XML file exist in the model data.
- Project status check – how far along are we to building a complete architecture.
And others I am sure.
Completeness Checking Important But Often Overlooked Check on EA
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 more information, including a link to a YouTube video demo, please visit the EA Frameworks Products page.
For a free trial of this macro and for many other macros, visit our free products page.
Modified on by LouV
On the flight back from an enterprise architecture conference, you are writing a presentation for the CIO, business owners and IT managers at your company. The message is simple: we must begin an enterprise architecture program to bridge the chasm between business and IT. In the past three days you’ve been taken to the mountain – several times – and you want to share that new-found knowledge and passion with those who can now make this happen.
You rehearse your presentation in the airline seat. You predict that point at which the light bulbs will go on, and there will be universal agreement that EA will address all of those gnarly problems that have been bedeviling the company for years: the inability to assess IT investments in terms of business value; the lack of end-to-end views that show how business goals are supported by specific IT capabilities; little or no standardization among solution designs.
You then look a bit further into the future. As IT begins to develop and release solutions that address the real needs of the business, your star begins to rise in the organization. You will be heralded as the hero who brought order to a hopelessly chaotic situation. A corner office. Then, “Ladies and gentlemen, in preparation for our arrival, please …”.
Concrete vs Theory
A word of caution is in order. Increasingly, business and IT managers are looking for near-term benefits. Value propositions must be stated in terms of concrete results, not just theory. Enterprise architecture is a means to an end – probably several distinct ends – and these need to be articulated as part of making the case for EA.
In some cases it may be best not to push “enterprise architecture” but instead propose a systematic enterprise-wide (or business unit-wide) approach toward addressing some of your current challenges. Look at those challenges and, with the assistance of others, prioritize them. Then reach into your toolkit for enterprise architecture and select those techniques, governance processes, roles, artifacts and tools that would best fit the problems at hand. While many EA approaches speak of starting with corporate strategy and flowing down to business models in each line of business, you may find that the starting point is at the application level. Oftentimes, rationalizing the application portfolio across your company will yield tremendous value for the organization while setting the foundation for a wider adoption of EA to address other problems.
An Ever-Widening Circle of Stakeholders
Organizations that have institutionalized enterprise architecture and are regularly updating current and future views and feeding this information into the annual capital planning cycle, did not arrive at that level of maturity overnight. In nearly every case, EA starts with small goals, demonstrating a series of modest successes which in turn enlists the support of wider circle stakeholders. Eventually, there is a willingness on the part of senior management to invest in enterprise architecture, elevating it to a funded program with dedicated resources. Along the way, credibility is earned in increments. The decision to fund an EA program then becomes not so much a leap of faith as the next logical action to take.
So write that presentation on your flight back from the conference and keep your passion. But save the presentation until you have a number of smaller victories using EA approaches to help solve near-term problems.
Modified on by LouV
I recently did some work on importing DoDAF2 data from SV-06 spreadsheets into System Architect's DoDAF2 implementation and published a developerWorks article based on it. Importing DoDAF2 data into System Arcitect using the technique described in the article requires that you use version 184.108.40.206 or later as the GUID keys were removed from DoDAF2 in that version. Sample spreadsheets are accessible from the article which is available here: http://www.ibm.com/developerworks/rational/library/share-dodaf2-data-rational-system-architect/index.html
Modified on by LouV
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 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 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.
Modified on by LouV
You can look at the world around us as categorized into three kinds of relationships – Explicit, Implicit, and Inferred.
Explicit Relationship -- Like a Marriage
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).
Implicit Relationship -- Like Twitter
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.
Inferred Relationship -- Like 'Six Degrees of Separation'
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’.
In IBM Rational System Architect, you can automatically visualize all of these relationships on any diagram type. Functionality was added in SA 11.4.1, 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 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.
Modified on by LouV
In this blog, we want to say a bit about one of the biggest hurdles facing the creation of an ‘up-to date’ and ‘actionable’ EA – management of it. This is probably THE biggest hurdle facing a successful EA effort; for many years it’s been at the top of the list of why EA efforts fail or aren’t even attempted.
Documenting, Not Architecting, the House
First an analogy. Building an Enterprise Architecture for an organization has been likened to designing a house. But it’s not really like that at all. When you build the blueprints to design a house, they pretty accurately reflect the house that you’re going to build – the builders use those blueprints to build the house, and those blueprints had better be pretty specific down to the millimeter on how the joints will interconnect, where the plumbing will route, etc.
What Is and What ‘Ought to Be'
When an EA effort starts up, the house is already built -- like it or not. The EA effort either documents what already exists and what how it will be reachitected in several years, or what should exist. It is fools’ folly to try to document the organization down to the most finite level of detail. Unlike a house, the organization is constantly changing in structure. For an old house, you might change the faucet on a bathroom fixture, or even change your pipes from the street from galvanized to copper, but the plumbing design remains in tact.
In an organization – even if it’s an old organization that’s been around 100 years – your processes will constantly change, on a regular basis (in some organizations every six months). Your network infrastructure will move like a rug beneath you. Your organization could be constantly growing in size, taking over other companies with their own set of processes and networks and databases and organizational structures that have to be merged into yours. Your processes will constantly be changing, and your organizational makeup will change even faster – people leaving, new people coming in, and people changing roles and needing to understand how to get things done.
How Much EA Is Enough?
So the challenge to the EA effort is to capture as much information about the current enterprise architecture to make the EA relevant – something that you can make decisions off of, and get value from. Those are two distinct and perpendicular benefits – you don’t have to make decisions off an EA to get value from it. Providing timely and accurate information to your stakeholders – which can be every employee in an organization – is a tremendous value. Put something out there that managers and other employees (your 'stakeholders') can view, analyze, and latch on to – say ‘hey this is great – this gives me something valuable I didn’t have before’. Before you know it, word of mouth will spread and other divisions in the organization will want some of that too.
Carrots Are Good for You and Taste Great!
Most successful EA’s that we’ve seen start off small. As one of our customers once described it, you have to put the carrot out there, and then pull the carrot in when you get nibbles. As an example, we’ve seen a number of architecture efforts that started in a particular division of a large corporation. They documented a set of business processes, and hooked them to the networks and applications that served those processes. Further, they created live links in the tool to sources of record – other tools where those networks had been documented. The coupe de grace is publishing that architecture to a website hosted on the company intranet where everyone can view it. Users were able to navigate the business processes, and dig down to the network architecture and applications used, and then traverse further by clicking on reference links in the published architecture, to burrow down into sources of record for the network applications, servers, databases, and so forth. Tools used: basic System Architect with the SA/Publisher add-on.
Solutions to Help You Jump those Hurdles
Within IBM Rational’s System Architect labs, we’re working away at more functionality to further success stories such as these. And we’ll talk about this in excruciating detail as these blogs continue.
Modified on by LouV
Years ago, when Popkin Software was a company going from 45 people (when I started), to 75 people, to 100 people, to 125 people (and was then bought by Telelogic, which was later bought by IBM), I’d often pass by the front desk area and watch folks who were manning the phones play some sort of video game in their spare time to idle away the in-between phone call minutes. And I thought to myself if only we could make enterprise architecture like a fun game to play, we’d have even the people at our front desk helping us put the tool through its paces, build examples, and so forth. If a game like SimCity can be so popular, why not Enterprise Architecture? To me, documenting the organization’s important processes and getting a clear look at the network infrastructure in place or needed to enact those processes is fun. To others, perhaps viewing the output is interesting, informative, valuable, awesome and far out, but building the architecture not necessarily ‘fun’.
Simulation is the closest sub-aspect of enterprise architecture that I’ve seen that could readily be migrated to a ‘fun’ video game. It gets your brain thinking, and you can see the output animated on your screen, with little icons representing your game ‘tokens’ running through the simulated process flow diagrams.
Fun and Valuable
Not only is simulation fun, it’s valuable. First, it enables you to examine key business process flows, and – while putting in simulation information – drives you to adjust those flows to represent the actual business as closely as possible. You find yourself adding in decision gateways, additional processes you hadn’t thought about before, what kind of information is passed between parts of the organization and other organizations, examining your business to understand what kind of probabilities to enter at gateways, etc, etc, and so forth. And then – push the button and watch it all unfold in front of you. Second, you get valuable information on all kinds of automatic measurements and reporting statistics, like Six Sigma results (how your organization is achieving its goals – we’ll cover this in an upcoming blog), where your bottlenecks are, how your bottlenecks can be alleviated by adjusting the process or the manpower put on it, process optimizations, and so forth – and at the end of the day, provide reports to management that have some statistical analysis backing them up. Fruit for an interesting conversation and ammunition for a powerful argument.
Fun Videos to Watch
Here are some fun and interesting videos to watch on System Architect's simulation of business processes:
Modified on by LouV
We sometimes get the question from customers: what kind of skills should they look for in the people they want to add to their EA team?
My answer is that an EA team should consist of people of varied competencies, but at the core, you need skills along the lines of those that a journalist has.
A journalist doesn’t necessarily have to be a good writer (although it helps) – a journalist is someone who uncovers and documents the truth.
Enterprise Architect as Journalist
Here are some features of the enterprise architect as journalist:
1. It is a person with good people skills, who can pick people’s brains without causing them consternation or stress.
2. The journalist is a communicator who can express the value of EA to stakeholders -- not that it is an ivory-tower, anal-retentive exercise, and also to alleviate the fears of people in an organization who think EA or more specifically, business process analysis (BPA), is something that the company is doing to promote efficiencies and lay people off.
In the nineties an acronymn 'BPR' became dreaded in the workplace. It stood for Business Process Reorganization. Just that word ‘reorganization’ was one that struck fear into most of the workplace. I worked in a large systems organization at the time, and we all hated those ‘BPR’ people. They were going to come talk to us, without knowing or caring about how we built great systems that we sold to our customers, and change things. They were bean counters who were going to nit pick and find ways to figure out who they could lay off. The acronym was doomed from the start.
What needed to be communicated was that making the organization more efficient shouldn’t mean layoffs – it should mean making the organization stronger, having everyone more knowledgeable of how to get things done, building better products faster, etc.
As Scott Ambler said in an original comment to this blog post when it was on EABlue.com -- "Good EA's have great “soft” skills. They work closely with the stakeholders of their work, communicating their vision, listening to their stakeholders, and evolving their vision over time."
3. It is someone who can get answers to the questions who, what, where, when, how, and why. The answers can come from picking people’s brains, and using state-of-the-art tools to interrogate existing systems and sources of record– something we at IBM have termed ‘harvesting’ the enterprise architecture. To harvest information, some technical skills may come to the fore, but that’s not necessarily the journalist’s job – thus the reason why you need people of some diverse skills on your EA team.
4. It is a person who will not accept one answer as the answer. Often times it means talking to people in several departments, with several views of what’s going on, to uncover the real truth. This is also where tool automation comes in -- the EA tool, harvesting from several sources of record -- enables the Enterprise Architect to run reports to find redundancies, discrepancies, and gaps.
There are probably more skills of the journalist as enterprise architect – you can feed back more qualities if you think of some. You might also suggest who, in the back of your mind, you fancy yourself as, as you go about your daily job – Bob Woodward or Carl Bernstein, Lou Grant, Clark Kent, Lois Lane, Jimmy Olsen – it may depend on what organization you’re working in and how many hurdles you have to leap.
Modified on by LouV
IBM Rational System Architect is an Enterprise Architecture tool capturing the complete Enterprise's components such as the Strategy, Business, Information Systems and Technology.
Often in an enterprise capturing the relationship between these components are difficult to trace leading to different views of business decisions across organizations.
IBM Rational System Architect helps an enterprise to capture the data, creating the relation and analyze the data across the above said components.
IBM Rational System Architect's capabilities in a nut shell
Wondering what the above picture is all about?
Please visit us @ IBM Ratioanal Innovate 2011 for detail explanation and to know the capabilities of Rational System Architect.
Register on the IBM Rational innovate 2011 website @ Bangalore for more details ...
always looks forward for growth. With growth come the challenges such as
changes to the organization, resources, etc… that the enterprise needs to face.
Whether the growth of an Enterprise is through the merge or
acquisition or by itself change is immortal.
changes bring the challenge of instability and confusion which gets answered by
time. But for an enterprise it costs a lot when it is realized that the chosen
path is wrong after implementation. Enterprise Architecture comes as a savior
for these situations.
When the available data is collected and fed to an
Enterprise Architecture tool such as IBM Rational System Architect, the
descriptive Analytic can be done which can detail on what is related to what
from human resources to systems.
Also with the current state, enterprise can build on the
future state and also can predict the future of the enterprise and do a
predictive analytics. The predictive analytics helps the enterprise to realize
its future virtually without investing any cost/resource.
What else does the enterprise need other than predicting the
future with zero investment?
To know more about Enterprise Architect and System Architect please meet us in IBM innovate 2011 @ Bangalore
If you're a student, you can also win free passes to Innovate by
blogging or tweeting about rational products (use hashtag