Calling in the EA Troops


This past week seems to be the week for the call to action for Enterprise Architects to start blogging. James McGovern called out that there should be more EA blogger’s. More blogger’s came into the fold such as Brandon Satrom who would like to see more on how EA’s address some of the latest IT trends such as: S+S, user experience, OBA, ECM and more. While Todd Biske chimes in on the outlines some of the challenges Corporate Blogger’s face. A fellow Microsoft blogger Nick Malik whom is an Enterprise Architect for MS always writes about interesting topics around SOA and EA.

Overall it looks like I picked a good time to start blogging about my EA experiences. Beware, this could be a long post…

Over the past year here at Microsoft I have seen that there is a substantial need from the IT community for EA guidance. This derives not only from what I’ve seen in the blogosphere but what I hear from both customers and events in which I present. With my role at Microsoft I have had the privilege of speaking to a great deal of system integrators, independent software vendors and financial services executives at Microsoft Executive Briefings or as we call them EBC’s (everything has to be an acronym, huh…). Through these I talk to a load of CxO’s, chief architects and senior technologists.  Most times when I chat with senior level IT decision makers it’s less about the technology and more about the "Business of EA".

So what does the Business of EA mean? Well it’s more about how an EA organization operates such as: how it engages with the community, how it obtains community support/trust and how it is measured.

There are a set of common questions that I hear from fellow EA’s and CxO’s:

  • What is the right level of governance?
  • How do we overcome organizational barriers?
  • How do we become change agents?
  • What are the proven tools to help me in my efforts?
  • What are some metrics in which we can demonstrate our value?

It’s less about what is the right SOA or ESB, rather how do we get our "shop in order" so we can execute on these technology strategies. Personally I believe that the technology is easy to solve, however the softer skills are much harder for IT folks in general. The technology part of EA (i.e., Solution Architecture) is a challenge but is often overshadowed by getting EA off the ground and operating efficiently. This isn’t just the case for immature EA organizations it is true for more mature EA organizations. Doing the right thing often means different activities as an organization matures.

For example, processes that were defined when an EA first started may have less stringent guidelines, intentional gaps in process and light governance. Whereas more mature EA organizations have adapted over time to their unique business drivers and specific organizational cultures. Additionally these may differ from business to business. Manufacturing EA organizations are more interested in creating agility whereas a Financial Services EA is more concerned with risk mitigation in their policies and architecture. When we talk about the business of EA there are many factors most of all…. the business.

Since the rational of this post was to highlight my agreement for the EA calling of arms I do want to comment on what some others have said about this topic. I really liked Todd Biske’s post in which he talked about the fact that there are not many corporate IT blogger’s. See below:

As James McGovern has lamented in the past, and Brandon Satrom recently, there really aren’t a lot of enterprise architects working in typical corporate IT blogging. By typical corporate IT, I mean at companies whose primary business is not technology. I don’t know if this carries over to other roles within IT, but I suspect it does. So, is this is a bad thing? A good thing? Some companies may have formal policies regarding blogging, some may not. It can be a complicated issue, however, I do think that there is one basic factor that comes into play, and that is trust. For the purpose of this conversation, I’m going to restrict it to where people are blogging about the domain in which they work. So, if you’re an enterprise architect, this is relevant if you want to blog about enterprise architecture.

I have bolded the questions Todd asks about EA’s blogging. I think if corporate EA’s start blogging about their experiences that it would be a great contribution to the overall understanding of the EA practice. The information and lessons learned could dramatically help folks that are struggling with this in their businesses. I encourage you! Obviously there are IP and competitive forces at play when you blog, but I’m sure you EA’s know better. 🙂

As for James McGovern, I think he had a great idea about EA’s in the federal government.

My current thinking says that we should direct this call to action directly at the respective Chief Architects within the Federal Government…

And there is Brandon Satrom who has some very good statements/questions on EA and Solution Architecture.

1) What are some proven methods around iterative EA? We’ve all heard the chant of “Future State-Current State-Gap Analysis-Migration Plan” enough to have it embedded in our souls, but how do we leverage these good ideas in a way that doesn’t relegate EA to functioning as a team of Binder Boys?

On this one, I am a strong proponent of using EA Meta-Data Repositories. I will post about my thoughts in greater detail later. My last role as an EA at a large financial services company I lead our repository initiative which was more than a catalog but a living breathing entity that united our our architecture strategy (Transition State Architecture and Future State Architectures) with Current State. With this base data we linked in other aspects such as Risk Management, Incident Management, Project Management, Portfolio Management and Configuration Management. We had most of it complete before I left and was essential to not making us into, what Brandon says: "Binder Boys".

2) Folks like Simon Guest with Microsoft (and many others), have started to collaborate with the User Experience community (The likes of Lou Rosenfeld, Peter Moreville, Jesse James Garret) for more interplay between Architecture and UX. Is this part of a bigger trend of moving away from EA as process and into EA “for the people?” I, for one, would love to see that happen, but what does that mean for the process- and framework-heavy aspects of traditional EA (I’m looking at you mister Zachman)?

Simon is great, I think he is doing some great stuff around UX. He has really started this whole movement here at Microsoft. And I’m not saying this because he is on my team or that he sits a few doors down… 🙂 Simon is onto something here, as EA’s we need to think of the business and the user is what really enables the business. With that thinking we need to be very concerned about the UX aspects of our solutions. And I do not mean if it’s pretty or not but if it increases value to my business users.

I do not thi
nk this means a heaver framework, just changes to how we approach UX and information architecture. Yes I said it, information architecture, which we are really lacking in right now.

3) How does well-run EA best serve an organization first instead of worrying about controlling its decisions? On that note, how does well-run EA best serve its stakeholders first?
This one is a loaded question. Very simply I believe that developing a set of principles, policies and standards with your stakeholders gives you the structure necessary for both alignment and support by your stakeholders. This buy-in is how you keep focused on what really matters for the organization.


4) Is Microsoft on to something with this OBA thing? For that matter, are we really there with Composite Applications? Personally, I see this very idea as an evolution of Enterprise Architectures which serve the user by creating naturally productive applications, but what do others think?

So I have been doing a whole lot of ground work explaining what OBA’s are and how to use them in the industry space this area for the past year. I was also very fortunate to have Mary Jo Foley of ZDNet comment on my blog saying it is a must see for all things OBA. I recently developed an Office Business Application (OBA) for the financial services industry that was built on an SOA architecture. I classify it as an Enterprise OBA. I agree with Brandon on this one as well. I see OBA’s as the face of SOA. This bridges so many architecture concepts together such as UX and SOA (SaaS, S+S, Composite Applications). I have written some posts about this, check them out:

If you want more you will have to just check out the blog… 🙂

5) How can an organization already in bed with a major software vendor more towards welcoming open source where it makes sense? What experiences have others had in this realm?
I think that Dave Linthicum makes some great points on the "big stack vendors" and the challenges associated.


6) Is ECM mature enough to be of strategic value to most organizations, or does the visible lack of standards and market volatility mean that we aren’t there yet?
ECM is crucial to most organizations especially the ones highly regulated such as: Financial Services, Healthcare and Government.


7) Is it okay to have a list of random EA questions and not ask any about SOA?… crap.

LOL… Brandon, your in the EA dog house now.




Greg the Architect


I ran across a series of really funny architect videos that are similar to the ones my team published some time ago with Skyscrapr. We only did one video but it was really popular. At any rate, Greg the Architect is pretty funny and is really accurate on the challenges that architects in general face.

Watch "Focus Pocus" which aligns really well with my thinking on Enterprise Architects.

You can find more on Greg here:

SOA this. SOA that.

ROI of the Beholder



You can find more on Greg here:

SOA this. SOA that.

ROI of the Beholder



You can find more on Greg here:

SOA this. SOA that.

ROI of the Beholder



A Day in the Life of an Enterprise Architect

I am writing an MSDN article called "A Day in the Life of an Enterprise Architect" that hopefully addresses the many challenges an EA faces every day. The article is in the final stages of publication so it should be available on Enterprise Architecture Center soon.

Below is a small snippet from the article:

A good way to compare enterprise architects with other types of architects is to look at them in terms of Breath vs. Depth. This shows us how deep in expertise (i.e., “Depth” in Windows Infrastructure Architecture) versus the span of responsibilities in which the architect covers (i.e., “Breath” in a Line of Business (LOB)).

As shown below in figure 1.0, enterprise architects cover the breath of IT and to a degree the business concerns as well. When compared to the other roles you can see that the expertise of an EA is very different than the other roles.

Let’s take a look at how these roles are different from each other based on “Breath vs. Depth”:

  • Enterprise Architect – Enterprise Architects span across LOB and IT domains such as: Security, Infrastructure, Information or Development
  • Domain Architect – Architects that focus on a specific domain and have deep expertise that area are domain architects
  • Developer – Developers focus on one solution at a time and have a deep expertise in development


Figure 1.0

Above shows an enterprise architect in contrast with other architects. There are many different architecture operating models. The roles shown above are a sample of a structure that demonstrates how each of these roles aligns.


Figure 1.1

Above in figure 1.1 are two examples of two diverse architecture organizational models. The line in the middle separates out the two models. With each one of these it can impact the role in which an EA operates. With each comes contrary organizational and operating challenge.

Therefore, there isn’t just one criterion for making IT decisions. Decisions are made from multiple perspectives. Often times these decisions are not made based on the merits of the technology in question. Most times it boils down to organizational aspects such as cost, personnel supportability issues and IT standardization.


Keep an eye out for the MSDN article.


TechEd Australia and New Zealand


TechEd Australia and New Zealand are coming up quickly! I have speaking slots at both events.

Architecting Next Generation Business Applications

The way we architect solutions today is very different than in the past. There is an increased focus on the business agility and user experience. In this session we will discuss new approaches for architecting composite business applications.  Using the new 2007 Office Server System we explore the new development paradigm Office Business Applications (OBA). By combing service oriented architecture concepts with OBA we bridge people, process and technology.

The session schedules for TechEd Australia and TechEd New Zealand are here:

Australia Sessions
New Zealand Sessions

Australian Government Architecture Reference Models (v1.0)

The Australian Government Architecture (AGA) is intended to assist in the delivery of more consistent and cohesive services to citizens and support the more cost-effective delivery of Information and Communications Technology (ICT) services by government, providing a framework that:

  • provides a common language for agencies involved in the delivery of cross-agency services;
  • supports the identification of duplicate, re-usable and sharable services;
  • provides a basis for the objective review of ICT investment by government; and,
  • enables more cost-effective and timely delivery of ICT services through a repository of standards, principles and templates that assist in the design and delivery of ICT capability and, in turn, business services to citizens.

This AGA Reference Models document describes the first release (Version 1.0) of the reference models that will form the basis of a common language between agencies and structure a repository of architectural artifacts (including standards, guidelines, designs and solutions) that may be utilized by agencies to deliver an increasing range of WofG services.

The AGA Reference Models are managed by the Department of Finance and Administration, through AGIMO, in consultation with the Chief Information Officer Committee and the Australian Government Services Architecture Working Group.

Version 1.0 of the reference models was endorsed by the Chief Information Officer Committee on 5 April 2007, and contains the Service, Data and Technical Reference Models. The Performance and Business Reference Models will be progressively developed and released in future versions.

Requests and suggestions for change to these reference models should be forwarded to AGIMO at

Australian Government Architecture Reference Models [ – 2.5MB]The taxonomies for the Service and Technical Reference Models have been provided in a graphical from as mind maps. These can be downloaded in PDF or Image format.

Service Reference Models [ – 37KB] | Image Format [144KB]

Technical Reference Models [ – 16KB] | Image Format [52KB]



Is Enterprise Architecture Declarative or Imperative?

I ran across an blog posting by Brandon Satrom called "Is Enterprise Architecture Declarative or Imperative?". It was an interesting read. I agree with some of the concepts that EA’s should interact regularly, however I don’t really like using the terms Declarative vs. Imperative.

See below:

When I was working on The Great Buy vs. Build Debate – Part II last week, I briefly mentioned that the configuration of a purchased application often takes the form of declarative programming, where a developer instructs a system in what to do, but leaves it to the system to decide how best to implement that instruction. Contrast this with imperative programming, where the system is told both the what and the how. In a moment of rabbit-trailing, I started to think about these terms as they relate to human systems. Specifically, I wondered: Does Enterprise Architecture, as an organizational function, serve better by interacting declaratively with implementing teams, or should said function be imperative in nature? Personally, I think that EA is meant to be declarative and should interact regularly with a group of implementing architects (we refer to them as Solution Architects) who “sync up” with these declarative visions and translate them into execution.

I believe that Enterprise Architecture is all about fostering community, provide the frameworks for decision making and provides assistance on mission critical projects. It’s less about "telling the system what to do" rather fostering collaboration with these teams. When EA’s go in by force they are viewed not only as Ivory Tower but as Traffic Cops. EA’s should step back an enable and empower the community to make the right decisions, this gives EA’s creditability and support because they are not viewed as micro-managing.

Additionally sometimes Solution Architects (SA’s) or as I refer to them Domain Architects; do not apply in certain situations. I would be careful there for that reason and that not all organizations are structured the same.

For example below are two organizations I have had interactions with over the past few months:


One is structured around the Org Chart the other in a domain model.

Lastly, I would check out Todd Biske’s post regarding this as well. He has some good thoughts around transparency around the interactions between teams. He focuses a lot on the Solution Architect role, I agree with that however I think the higher order bit here is that EA’s and SA’s facilitate the change they do not micro manage teams. If they do resistance will be found and the organization rebels.