Using System Architect to Scare Sales People

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.

Iron Architect

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…

Architecture-Based Analysis and Decision Support (Part 1)

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:

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

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.

ArchiMate Support in 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. 

Show Me the Metamodel

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!

Explicit, Implicit, and Inferred Relationships

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.

From tribes to nations

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.

What if Basil Fawlty used IBM Rational System Architect to optimize his hotel booking process?

Check out this great video of Simulation and — importantly — Optimization of a process flow using System Architect’s simulator, powered by Lanner’s Witness simulation engine. Those crazy Brits!

http://www.youtube.com/watch?v=rYEC81kmXWM

The Value of becoming a Certified Enterprise Architect

If you’re reading this (thank you), then you have more than a casual interest in enterprise architecture.  You may be a seasoned practitioner, or someone who has recently been introduced to the field, or (most likely) somewhere in between.
Anyone who has spent some amount of time in the field knows that this is a relatively young discipline.  Yes, the underpinnings of EA – systems theory, organizational dynamics, model building and component-based design (to name a few) – have been around for some time.  Just as never-seen-before molecules are combinations of a base set of elements (112 by some counts), so are new and valuable applications of enterprise architecture emerging out of industry, government and academia.  In my view, we have only begun to reap the business benefits of architecture as an ongoing practice to direct the course of organizations in an uncertain world.

Among the readers of EABlue, it is safe to say that we are all students of enterprise architecture, continually striving to integrate architecture with day-to-day operations and finding innovative ways to make EA “actionable”.  One area that I believe deserves more attention is the interplay between enterprise architecture and solution design (watch this space for a blog on this topic).

If you’ve been involved in an enterprise architecture program, you quickly build up a repertoire of war stories.  The great thing about other people’s experiences is that you can reap all the benefits (well almost) of what they learned without necessarily going through the same painful and blissful experiences.

Which brings me to the point of this blog.  I am proud to announce the availability of an EA certification course series from IBM Rational.  Many of you may recall that we had partnered with Carnegie Mellon University in offering an enterprise architecture certification program.  That program has been re-launched, but with some changes: the materials have been updated, the duration of the three classes are normalized, and we are now partnering directly with Dr. Scott Bernard as the principal author of the curriculum (along with IBM).  Students who successfully complete all three courses (there is also a 10-day boot camp) will receive a Certified Enterprise Architect certificate from the International Enterprise Architecture Institute (iEAi).

As one who has had the privilege to deliver this material previously, I am very excited that we are able to offer these classes on a public and an in-house basis.  I learn new things each time I teach a class, and the same can be said of the other instructors, I’m sure.  Not only is there value in the material that is presented (which is augmented by the instructor’s experience in the field), but students find a treasure trove of shared experiences from the apprentices, journeymen and grizzled veterans alike who make up a typical class.

The three courses are Basics of Enterprise Architecture, Applied Enterprise Architecture, and Advanced Enterprise Architecture.  The courses are designed for those who are, or will be, participating in an enterprise architecture program, or those who have responsibility for the outcomes of an EA program.  You will learn how to make a business case for EA, the importance and history of enterprise architecture frameworks, how to identify the capabilities for a future architecture, and how use EA as a means of aligning the organization to articulated business goals with emphasis on IT investments, to name just a few of the topics.  Perhaps most is important is how EA integrates with the governance and decision-making processes across the enterprise.

As enterprise architecture is yet an evolving discipline, having credentials from two recognized organizations (IBM and iEAi) is a definite plus.  To be sure, there are other certification programs  available.  Some of these focus on one particular framework or approach.  However, the enterprise architecture course series from IBM Rational brings together the essentials of Zachman, TOGAF, DoDAF, the Federal Enterprise Architecture Framework along with Dr. Bernard’s EA(3) approach.  While there is no single way to do enterprise architecture, I would posit that there is a common set of principles undergirding virtually all approaches.  Among these is that the motivation for change can come as strategic direction, changes in the business model, or shifts in technology.  To effectively manage change at the enterprise level and to move the organization systematically toward a state that is animated by vision may define the agile enterprise.

I invite you to learn more.  IBM Enterprise Architecture course series.

Innovate 2010 – Get the inside scoop

We can hardly believe that Innovate 2010 is upon us.  You can find all kinds of things on the web site if you are looking for a general description as we head to Orlando, Florida on June 6, 2010.  But it’s only here in this blog that we are going to give you the inside scoop on what is in the Enterprise Architecture Management track.  Consider yourself in the know.  And if you haven’t already registered, get yourself there, you won’t want to miss this conference.

IBM EA Innovate Sessions

Our EAM track showcases real-world customer experiences using IBM’s EA offerings, including Rational System Architect, Rational Focal Point and Rational Asset Manager.  In the keynote, we’ll get real about organizations using EA and what kinds of business results they are getting.  There will be information about IBM’s vision for the future of EA and the broader Architecture Management story.  And a session which highlights what’s new in these tools and the value they add. If you have been following us, you know that IBM recently introduced advanced analysis and reporting capabilities into System Architect with new features and integrations and IBM’s powerful Cognos Business Intelligence tools built right in. These capabilities allow our clients to leverage the information contained within the EA with an easy to use web based interface designed for the business user, with capabilities that yield rich correlations and visualizations needed to simplify complex enterprise architecture (EA) relationships…. well, anyway, all the things our executive clients want to support decision-making at an enterprise level.  New capabilities will be highlighted in a session that focuses on integrating Enterprise Architecture, Application Portfolio Management, and Service Management solutions.  Our very own Martin Owen (IBM EA Product Management Lead) will take us on a deep dive – Upstream Planning with TOGAF 9.

Client EA Innovate Sessions

But we aren’t going to ask you to take our word for the value we know you can get.  There are 6 client sessions, covering topics like:

• Governing Service Development and the SOA lifecycle in the Enterprise using Asset Management
• How is EA used to make effective enterprise and IT portfolio management decisions
• How System Architect XT can be used enterprise-wide, providing real time visibility and enterprise reporting
• Visualizing Business Opportunity – using business and IT architecture models in Rational System Architect to identify actionable process, system, and organizational improvement opportunities
• Using EA to drive application and technology rationalization initiatives to reduce cost
• Defining and communicating the Enterprise Architecture across the enterprise centrally allowing teams to leverage assets globally.
• Describe current state and target state architecture using reference models like  IBM IFW, FEA and Rational System Architect
• Developing a  meta-model to capture information about IT Assets to support Application Portfolio Management
• Cataloging of services and automated diagram generation

Business Partner Innovate Session

We are especially proud that our partner, Armstrong Process Group (APG), a tremendously respected firm in the industry, will present a must-see session on building business reports using TOGAF architecture views.

Other Activities – Executive Summit, Fish Bowl, Expo Hall

We are running an Executive Summit concurrent with the conference, this is by invitation only, and several of our Executive level clients will join us in a unique exchange with their peers.  Fish Bowls are designed as highly interactive sessions in which you have a rotating panel, dependent on the level of contribution you can provide on a topic.  Our meant-to-be provocative topic is “Enterprise Architecture: Does it aid or impede agility?”  Come have your say.  We’ll have a few peds at the Expo Hall, and several demos tee’d up with experts who you’d normally have run beside to spend any quality time with.

We’ve been working hard, and we sure hope you will come and gain the fruits of our labor at the event of the year.

See you at Innovate!