So I figured since I already started a thread on the Gartner keynote (Gartner EA Summit – Emergence Enterprise Architecture Keynote) I should finish what I started, huh?
Just so everyone knows, this is Gartner’s London EA Summit event and not the North American event. It does seem a lot smaller than the other EA events. I am not sure if it is the case in attendance or just the facilities but it does seem a lot smaller.
I will do a recap of my key thoughts so far on the conference. I hoped around a bit between different tracks based on my interests. Keep in mind I am not going to divulge too much on Gartner’s materials here. I’ll mostly offer up my opinions on the sessions.
Understanding the Market and selecting an EA Tool
This was the first session I went to after the keynote. I think Robert Handler did a good job of presenting this topic but it is pretty clear that this is for folks that are new to the EA Tools space. For the most part it was very much 101. Keep in mind this isn’t a negative comment, just the context.
Even though it was some what beginner in nature there was some fresh and good nuggets in there that are worth pointing out explicitly.
- The notion that there is a trade-off between the Usability (Simple/Clean/"Keep it Simple Stupid") and Functionality (Rocket Scientist, "You want it, we got it")
- EA Tooling Status
- Recommended using Office or what is referred to as the EVP Suite if your organization is at a certain level of maturity (Gartner’s Level 1 – 2). This makes a lot of sense and this is the value proposition that we have proposed to organizations with the EATK.
What I did learn in the session was a status on the EA Tool vendors. If you follow my blog you may of seen my simple assessment of this space based on my experience. I talk a lot about the ability to execute, fragmentation of the EA Tooling market and so on. There were very similar themes in the status of tooling. One thing that I didn’t factor in was the consolidation of tooling and the impact on existing players. I want name names, but there were some well established names in the presentation that were mentioned as declining due to the impact of consolidation in the market.
One other observation here is that when Robert talked about EA Tools he evaluated them on features. While this has worked in the past, I think we should move toward a capability type of approach when evaluating tooling. I think we will start to realize that what we traditionally thought of a EA capability is really something we already had, such as workflow, security, ECM, repo, etc.
What’s Next: Context Delivery Architecture
This was an interesting one for me. When I looked at the title, I think I was expecting something much different. There were some things I liked about this topic such as the notion that this is another Architecture Style. I also, thought there were some interesting nuggets littered throughout.
However, I found there wasn’t much meat to the presentation. Maybe it’s too early, but I would argue that the Web 2.0 space is all over this and has a ton of great material. Microsoft as an example, is all over this. My colleagues back in Redmond such as Karthik Ravindran, Paul Stubs and Masashi Narumoto (see: Contextual Service, Contextual Service Example, Architecture for Consumer Oriented Services Cont’d) are doing some really cutting edge stuff around this very topic. I really didn’t see the holistic pitch around the space mentioning who and what are the key technologies to enable this space. There was a lot of redundancy around Facebook and Nokia. For example these were not mentioned:
- Myspace – Social Networking
- Twitter – Microblogging
- Microsoft – Live Services
- Apple – iPhone and GPS location aware apps and games, music recommendations, etc.
- Zune – music recommendations, subscriptions, social music aspects, etc
- XBox 360 – Gamer Tags, Persona aware, Messenger Integration
- Zooomr – Photo geo-tagging
- Plazer – Location Services with integration into blogs and micro-blog engines
There were also a lot of non-qualitative numbers being thrown around. There is probably more data points behind the scenes in research papers but would of really liked to see that information. Information like, where did this data come from that drove these predictions (enterprises, consumer application development, hobbyists, micro-ISVs, SMBs), probability of the prediction and the impacts on current designs and decisions.
I do think that this is going to be part of the future of IT especially as the next generation IT folks join the ranks. It is going to be expected that context services are enabled. The way in which we do things will seem somewhat antiquated to future generations and they will expect these automation services to be available.
Adapting TOGAF Globally
I both had the pleasure of attending Joel Goodling’s presentation and also having conversation over dinner as well. He did a great job articulating the value of the using a general purpose EA framework such as TOGAF.
He walked through how he configured TOGAF to fit inside his corporate culture. By being mindful of that terminology and existing organizational structures will play a large role in the success of TOGAF he did some very smart things like renaming the ADM phases. He also removed some of the ADM steps (mitigated that with baking those missing bubbles into other processes).
All in all a great session.
Communicating the Value of EA
I may of become a new fan of Brian Burke. He really hits the nail on the head. There were a ton of tips in this presentation that should really be taken by all architects not just EAs. I would of actually renamed the session to something like "Communication is key to an Architects Success". Needs a little work, but you know where I am going with it…
Even though this is still a bit of 101 as well Brian highlighted some good situational leadership ideas. He reinforced the need for clear communication plans and the notion of communicating frequently even if the message is going to change.
I wanted to give some feedback on some new thoughts from Gartner in their keynote on Emergence Architecture. Overall I thought it was a great keynote presented by Brian Burke and Nick Gall. It was somewhat of a different theme then in previous years. The keynote centered around "Emergence Enterprise Architecture".
So we see a new term call Emergent Enterprise Architecture. Is this yet another element to put in from of EA? I certainty hope not and honestly I don’t think so. So what is Emergent Systems/Enterprise Architecture?
Gartner started out with the wikipedia definition, so let’s do the same. Here is the wikipedia definition of emergent:
Science (from the Latin scientia, meaning "knowledge" or "to know") is the effort to discover, and increase human understanding of how the physical world works. Through controlled methods, scientists use observable physical evidence of natural phenomena to collect data, and analyze this information to explain what and how things work. Such methods include experimentation that tries to simulate natural phenomena under controlled conditions and thought experiments. Knowledge in science is gained through research.
I really like this approach which at the end of the day which encourages innovation and R&D by true SME’s in IT, Operations and the business units.
For me this really turns the EA Office into a function in which facilitates smart people to make aligned decisions.
The picture you see on the right of the hour glass is an analogy in which Gartner uses to describe this approach. The point here is that you should focus on the focal point. The focal point is the common denominator in solutions. As an example of a common denominator in lets say e-mail would be the MIME standard for defining e-mails. The common denominator does not define the consumption aspects nor the generation aspects but rather the common characteristics of an e-mail.
They also use the shipping container as a great example of this notion. They examine how a shipping container allowed the diverse and exploding business of international shipping by focusing on the common denominator, the shipping container.
I interpreted some high level principles for Emergence Architecture
- Self adaptable architecture efforts
- Generic personas that interact with architectures
- Loose Coupling to external forces such as geographies and regulatory factors
The showed one of the "mega" models which was coined as the Spaghetti and Meatball diagram. I like this phrase a bit and also recommend people to refer to the quote from George Box.
"Essentially, all models are wrong, but some are useful" – George Box
I think this is very true at least right now with the current state of many tools. It seemed that in the keynote that Gartner somewhat agrees with this assessment as well where they stated that models are often never accurate.
Another possibly controversial notion proposed was when looking at the model, the boxes are not the architecture but rather the lines are the architecture. I think that is a rather bold statement and I personally think that there is some truth there but not the complete picture. I view the "lines" as a cross cutting concern across the architecture.
Below is a Open Group / IEEE 1471 based view on architecture cross cutting concerns.
In summary, this session was one of the better Gartner keynotes I have been in (and I’ve been in a quite a few). It was extremely grounded instead of the typical ivory tower messaging which is sometimes conveyed at these types of conferences. This was more of a pragmatic approach, which I am a big fan. Ironically, there is almost complete alignment with the principles of the EATK (shown below) and emergence architecture. I have coined this as Enterprise Architecture 2.0.
- Introduce New and Creative Capabilities to Architecture
- Simplify and Consolidate Solutions for Architecture Design
- Leverage the Tools You Have
- Simplify the process
- Introduce Collaboration into the Architecting Process
- Surface Information in the Scope and Context of the Architect
- Every asset relates to another in some way
So if you have access to the materials from Brian Burke I would defiantly check out this new Gartner concept.
The EATK makes Microsoft Word 2007 a first class citizen in the architecture description area. As I described in my recent post called "Do Office Tools Still Play a Role in Architecture Design?" I talked in length how at least for the time being we are still using productivity tools for describing our architectures. Since this is the case more often than not, the EATK uses Word to articulate these architectures.
In this post I will give you a brief summary of how the EATK helps with documenting architecture descriptions.
There are a series of problems that the EATK is trying to solve by leveraging Microsoft Word 2007. I will not go into length in all of them but highlight some key areas.
The first is to make the creation of architecture descriptions much more intuitive and easy to do. Even though tools such as Word are easy to use we still see complexity here. That complexity comes in the form of:
- Duplicate data entry
- Template overload
- Limited ability to control quality of descriptions
As shown above, we are adding more and more documents to an already large portfolio of documents that need to be completed. In the past this was manageable but now documents can be bloated and information has a higher probability of being duplicated. Often times this is a result of tightly coupling a document with a process step that results in a great deal of redundancy.
So how does the EATK attempt to solve these challenges? It does so by changing the context in which Word is used. Changing the context is a sometimes not an intuitive task. It takes some investigative work both on the capabilities you want to expose and potential development to the tooling.
The underlining goal is to change the role of Word from simply a word processor to more of a User Interface (UI) for designing architectures. Applying structured UI concepts to Microsoft Word provide many benefits to the architecture document.
- Structured Content – Information can be better described in the document. The reason we want to do this is because of the challenges mentioned regarding how information doesn’t integrate well with process or future design activities. One example is the process of importing a model into an architecture document. Often times we import a picture that represents a model of a specific view point of an architecture. If we had an information model we could specific that the model imported is indeed the logical model, rather than a generic image file.
- Extensible – With a little more structure information has meaning and definition. This makes that information extensible to other processes downstream.
- Consumable – Abilities to consume external content is also possible with a more structured interface. As an example, if you choose to you could import external architecture information from other systems to automate you design efforts.
Let’s take a look at this from a technical perspective. Below illustrates how the EATK separates areas of concerns with the implimentation in Microsoft Word.
- Tool – The mechanism of Microsoft Word is referred to here. The tool provides extensibility into the user interface that provides Office Ribbons to execute tasks easily with a level of context and Office Task Panes that extend the UI with additional entry or listings of information.
- Document – The document provides the way in which a user can enter in architecture descriptions. This is different in the EATK as the document acts as the glue between the Tool and the information itself. This is accomplished through a architecture document template and the use of word custom controls.
- Information – The information in the document is managed completely different than in a traditional document. All information typed into the document is linked back to an XML node behind the scenes. This fully qualifies what is typed the information. Not only is the information rich but it is extensible.
Let’s take a look at the implementation in the EATK. Below you can see how Ribbons, Meta-Data Properties and Task Panes are implemented. The EA Toolkit Ribbon shows at the top of the screen. These represent the functionality the functionality in this tool.
The meta-data properties provide context around the document or high-level architecture itself. There are the following fields: Title, SDLC Phase, Architecture ID, Architecture name, Project ID. This information is utilized in throughout the implementation from integration to the workflow to surfacing information in context.
Task panes shown below are able to make architecture information as transparent as possible. It allows the EATK to surface information from the architecture meta-data repository. With a double click on a pattern or asset that information is populated in the document. The document tracks if an existing pattern is used so the governance process can track reuse (among a series of other benefits).
The new OOXML features in Office 2007 allows us to separate the information from the document in a much cleaner way. With the new formats, the entire document is XML based. The document itself is a zip compressed file with the extension of .docx. In these files are a series of file folders.
The customXML folder is used in the EATK. Below we see that item1.xml is the system architecture XML file used for storing architecture information. All information entered into the System Architecture Document will be stored here.
Additional Screen Shots
James McGovern made some great points about informal communication in his post The Lost Art of Informal Communication.
I think he makes some really good points about how pushing more structure on activities or a team can sometimes be bad. When managing projects to programs we need to be mindful not to let the process control us. We should be controlling the process.
I ran across an interesting post on J.D. Meier’s Blog that describes the Patterns & Practices project called the Application Architecture Guide Project 2.0.
Hosted on CodePlex.com this project aims to take guidance from Microsoft and marry it with the CodePlex community. In the projects own words:
The App Arch guide provides design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.This guide is a collaborative effort between patterns & practices, product teams, and industry experts
It’s a great idea, but like with all community projects it depends on contribution by the public. I am eager to see this one develop over time.