Do your Vendors have Enterprise Architecture Efforts?

The short answer is… Yes. But why do they? Aren’t they just supplying shrink wrapped applications. Why should they care about EA?

Over the course of the past six or so months I have hosted or have been hosted at events that relate to the practice of EA. What I found surprising is that there is a great deal of EA activity in the vendor space. I knew it was happening but not at this rate. I talked to a large financial services ISV that hired a chief architect from an enterprise. They wanted him to lead there re-architecture of the entire product line over the course of the next five years. He has built a mini EA-ish practice within the ISV. This is the case with one but there are many that are doing similar things with EA.


So why do they have EA practices? Simply, they want to manage complexity in the growing number of systems they have built. Not too different than others in the corporate space. Vendors often face challenges that contrast the issues enterprises faces. Even though there are similar challenges it is not to say they are the same nor can you use the same approaches to the problem. 

How do we differentiate between the two? Below is a chart contrasting enterprises with the vendor space.





What does this mean?

Business Alignment

Less of a concern for vendors. Market and Roadmap alignment is the primary concern in this space

Obviously this is a high priority for most enterprises

Vendors will spend more time on forward conditions rather than current and previous. Whereas enterprise must take into account these challenges as they as based on the fabric of their business.


Vendors must be able to support compliance

Enterprise have to implement compliance

Even though these are very different activities there is still a great deal of similarities and work to be had be the vendors. Not only does an individual product need to be complaint but the whole integrated suite of products.

Risk Management

Vendors have very different risk management controls. Usually less intrusive.

Risk management in enterprises usually has several functions to support operational risk and reputational risk.

Enterprises have much more activities when it comes to risk functions, but as you can see vendors have the same concerns but on a much smaller scale.

Cost Control

Usually vendors are more sensitive to this as their business is the technology they build

Still a concern to enterprises, however operational management functions often impact costs

Both vendors and enterprises share the same aspirations of lower the cost of ownership of their technologies and have similar processes.


Agility to a vendor is often looked at from purely a technology perspective

Agility in the enterprise  is often looked at from the business perspective

Perspectives of are different however they are both concerned with agility


This is the core to the vendors business

Most enterprises rely on
technology innovations from the vendors

Vendors have a stronger emphasis on innovation and structure their business and technology processes around this aspect.  This is one of the largest differentiation between the two.


Mergers are lighter weight and encompass merging of technologies

Mergers are on a much larger scale and include integration of business processes and technologies

Mergers will happen in both and will have similar pre and post processes even though efforts may be different.


Very light weight to encourage and foster innovation.

Heavier weight to regulate compliance and risk management within the enterprise

Vendors will have a much lighter governance model since innovation and time to delivery of products is key.

Portfolio Mgmt

Technology roadmaps and refreshes

Enterprise standardization and cost control.

Both will have portfolio management concerns.


In summary, even though there are some big differences between vendors and enterprises there is a great deal of similarities in the process of EA. Here at Microsoft, EA is not immune to the same challenges enterprises face. The processes around aspects such as governance and portfolio management have to be seriously modified to work within vendors. Does this mean vendors shouldn’t have an EA practice because there is loose governance? Absolutely not, governance is just one aspect of EA.

There is a great amount of EA practices among top software companies around the world. Some of the larger ones include; Microsoft, Sun Microsystems, Oracle and IBM. But this isn’t limited to large vendors. I’ve talked to three Financial Services vendors over the past year that have EA practices.

Enterprise Architecture means something different to every organization. It is important to understand that there isn’t a prescriptive model for approaching EA practices. It is about following a key set of EA principles instead of following a checklist.




Presenting at Three Architecture Forums in Canada


If you are planning on attending the Federal Government Architect Forum, British Columbia Architect Forum or the Financial Services Architect Forum from the 9th to the 11th of October you should stop by for my keynote. This is a great time to slot in side meetings over the course of the day or lunch.

Look forward to seeing you all there!

Gartner predicts that by 2012 40% of today’s enterprise architecture programs will be stopped

The End of EA?

I originally saw this on the following EA blog. He mentions that Gartner in it’s upcoming summit says that EA practices will diminish by 40% in the year 2012. This is interesting for many reasons.

Without seeing the actual content from Gartner it is hard to agree or not agree with the prediction. I would say that by 2012 EA functions will evolve. This will be necessary to stay relevant to the state of the IT industry.

The value proposition this function provides is a must for the future CxO. The EA landscape is starting to solidify as vendors buy up and consolidate the market. By 2010 I could see comprehensive EA tooling that will change the shape of how we do EA today. These tools will make our lives, more integrated, better connected to information, collaborative, and seamlessly injected in the processes required for EA’s to be successful. 

So whether we call it EA or call it by another name. I believe the function it provides will still be around in some fashion.

Tags: Enterprise Architecture

Enterprise Architecture is the next Hot Job

According to CIO magazine the Enterprise Architect is the next "hot job". The article in the Sept. 2007 issue walks you though why you should consider EA as a career and the skills you need to be successfully. They also give tips to employers to find you.

Just looking at the market and talking to our partners and customers it is becoming very clear. There are tons of interesting from the analyst community that also support this. Forester says that 90% of the fortune  2000 companies already have some form of an EA practice. We are also seeing a great deal of evidence in the EA tooling space where profits for these vendors are doubling year over year.

Snippet from the article:

An enterprise architect (EA) takes a company’s business strategy and defines an IT systems architecture to support that strategy, according to Jim Lanzalotto, vice president of strategy and marketing at talent and outsourcing firm Yoh. To do so, EAs must understand a company’s business and be able to dive deeply into technology issues. In recent years, the role has moved out of the banking industry to pop up all over the corporate universe as companies move to align business goals and the IT infrastructure that supports the business and helps achieve those goals.


Enterprise Architecture Analogy

I was talking to a colleague two nights ago and he asked me how I describe Enterprise Architecture. Immediately I have memories rushing back of when I was an EA and had to educate folks on "What is EA". I had two routes I could take in my response. The first was a complex and through explanation. The second a simple answer that relates to something we could relate to. I went with the latter.

I have been using this analogy for about four years now from my activities at the bank I used to work for. It doesn’t completely describe the EA function but it isn’t meant to. It is used to convey the general premise of what an EA function is.

I use the United States form of government as an analogy. As shown below there are three major branches; the Judicial, Legislative, and Executive.


You can see a ton of similarities here. I break these three forms of government into the following activities of the EA function:

  • Judge It – This area goes into the governance activates of an Architecture Review Board (ARB). Ideally ARB’s should have limited power and only have the ability to review architectures not to create the laws (i.e., standards).
  • Standardize It – When we talk about standardization this is the activity that forms virtual teams of domain stakeholders to build what is commonly referred to as Principles, Policies and Standards.
  • Execute On It – The executive branch in reality is the "commander chief" that is the official spokesman and stimulates action in time of need. Likewise with EA’s on strategic projects and management of future strategies.

Like with all analogies it’s not 100% accurate but it can be a power tool to convey a message. I was talking to Harry Pierson in Microsoft IT about this as analogy. He made some great points in challenging the semantic details. While I agree on those detailed points, I don’t think it applies to this analogy. The point of the analogy is not for communicating with people whom already understand EA but rather others such as developers, business representing or senior IT decision makers.

So what’s the point here for EA’s? Being able to articulate your function and purpose to your audience in terms they understand will greatly help you in your endeavors. This allows your audience to understand what you do and how you can help them. On the flip side, if they do not fully understand your role there is a good possibility that they will not engage. This isn’t because they want to, but because they do not know that they should.


Capital Markets Architecture Center Launched!

We launched the Capital Markets Architecture Center last week with loads of great articles. Stevan Vidich was critical to the success of this one.

You can find the capital markets page at:

Look for more great Financial Services guidance out on MSDN at: 




Why doesn’t Microsoft have any EA Tools

Serge posses the question in his post, Enterprise Architecture Tools: Why are IBM, HP, Microsoft, CA and others absent?. Unfortunately I do not have a good answer for that. However, we are working on some projects (not products) that may help lead us in that direction.

I am building a Enterprise Architecture reference implementation. This will be similar to a reference architecture. The Enterprise Architecture Reference implementation that will have a core set of assets avail for free to everyone.

I am building this out using the following technologies:

  • Microsoft Office SharePoint Server (MOSS)
  • Microsoft Operations Framework (MOF)
  • Direct integration with Office Clients (Word, Excel, Outlook)
  • Forms Services
  • SQL Server

I will be enabling several EA processes through the reference architecture. To name a few that are based on the four based EA tool capabilities:

  • EA Integration into the SDLC
  • Providing a better way to document and manage our architectures
  • EA Metrics generation
  • EA Community (Blogs, Wiki, E-Mail Guidance and patterns)
  • Linking key processes together (System design, Incident Mgmt, Config Mgmt, Risk Mgmt, Service Mgmt, etc.)

I would love to hear this communities thoughts on this topic and some usage patterns that you are struggling with. I presented on EA tooling at MS TechEd this year check out my blog ( on how I define the EA tooling space. More to come later of course. But this is your chance to get something build for free 🙂

Please keep in mind, my goal is to provide a way to make our EA efforts easier and solve some of the low hanging fruit, propose some alternative ideas, and provide some more practical guidance and tooling that will obviously be a starting point. This is not a full fledged EA tool by any stretch (without customization).

More to come, stay tuned…

To see what was in previous reference architectures see the Loan Origination Reference Architecture Framework located here: