Mike Walker's Blog

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.

 

	Vendor	Enterprise	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.
Compliance	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	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
Innovation	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	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.
Governance	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.

 

Tags: Enterprise Architecture

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

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.

Tags: Enterprise Architecture

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.

Tags: Enterprise Architecture

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:

http://msdn2.microsoft.com/en-us/architecture/aa902582.aspx

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

http://msdn.microsoft.com/FinServArch 

 

 

Tags: Financial Services

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 (http://blogs.msdn.com/mikewalker/archive/2007/06/05/my-enterprise-architecture-session-at-teched-2007.aspx) 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: http://msdn.microsoft.com/architecture/orlos

 

Tags: Enterprise Architecture

The Enterprise Mind? An in depth look at EA Tooling

This is a great starter article for folks wanting to evaluate EA tooling. I have blogged and spoke about this at conferences in the past about how EA tooling is all over the place. From what I have observed in the EA industry for over the past five or so years there is this notion of building EA organizations solely around one framework. This is simply not practical for so many reasons.

(I have represented this in a few ways in the past but I really like how they represented this, I may have to adapt this heat map type of method. With a few more data points on here it would be perfect)

The largest issue by far with EA frameworks is that they do not cover the full spectrum of EA needs. So we are left with a lot of EA Frameworks and even more home grown frameworks that are tailored to organizations that had built them.

The article called Enterprise Architecture Tools: What is in the Enterprise Mind? goes into  a concept of an enterprise mind and the tools to satisfy the needs if the enterprise mind. So check out this article, it is a great primer for EA tooling and has a high-level evaluation matrix. It is not a comprehensive matrix but it gives you some good questions to ask yourself when evaluating.

Additionally, if you are serious about evaluating EA frameworks check out the following resources:

MSDN EA Center - http://msdn.microsoft.com/architecture/ea

How to Survive in the Jungle of EA Frameworks - http://www.trafford.com/robots/03-1984.html

 

 

 

 

Tags: Enterprise Architecture EA Tools EA Frameworks

Is EA becoming a Trusted Business Partner?

I read a recent survey from InfoSys where they surveyed a number of EA organizations. I was surprised by the outcomes. Check out the stats:

• 36 percent of EA teams surveyed actively participate in their company's strategic business planning.
• 19 percent of all EA teams spend most of their time on Business Architecture, a 36 per cent increase vis-а-vis last year’s survey.
• 20 percent of the companies have the architecture function reporting at the corporate level, a reflection of the increasing relevance of EA.

This is great news if this is truly happening. The customers I have been talking to of late are still struggling a bit with this becoming that trusted partner.

 

Tags: Enterprise Architecture

Obtaining Enterprise Architecture Metrics - Part 2

In my last post I talked about "keeping EA metrics on the trail" and what you need to think about when gathering the right metrics. By understanding what you need and pitfalls to avoid including common mistakes when gathering metric and tips on what you should be looking for when gathering these metrics. I will now talk about some ways in which you can figure out the value of your organization.

The problem you will have is that there isn't a prescriptive way you can measure your organization. There are the following factors:

• EA Charter - Not all EA organizations are defined in the same. Since there is little definition of what an EA organization should be there is a degree of  variances EA responsibilities per each organization.  
• Organizational Culture - Some cultures such as the ones within software vendors have a culture of being innovative, these cultures will push back on the slightest bit of governance. However, if you look at a bank they encourage more structure due to their culture being risk adverse in nature to run their business.
• External Forces - Reactions to the market or regulatory concerns often effect what EA's do. Be prepared to adjust your metrics.

Since we have many factors that go into this, I am going to be somewhat generic but try to give you some solid all-purpose guidance for obtaining metrics. Bare in mind, keep your ego out of the metrics discussion. You want to prove the value of enterprise architecture and not the value of Joe Smith who is an EA.

If we look back at the previous post we want to look at the three data points EA's should gather.

• Obtain the Information
• Process
• Communicate

First is to obtain the right information. But what is the right information? Should we be focusing on how to align this with the business or with IT activities? The answer to this is that it depends... It depends because these answers hinge on the maturity of your EA and organization as a whole. However, in most organizations we are on the slightly less mature side so that is what I will focus on.

EA organizations rarely report into a CEO or Business unit. There are a few companies out there that do but this ideal state is something that most business do not do. On a side note, this is unfortunate because this is ideal for EA's to report to the CEO rather than the CIO. Most EA organizations report to the CIO or below. This has implications on EA's. What it means is that your in the IT organization and at the end of the day you are measured not on the business but on the health of your IT organization. So to go back to the questions posed, you should focus on IT activities when building metrics. Does this mean you should exclude business alignment, absolutely not! However you should realize that you are ultimately accountable and responsible for IT, not the business.

Now that we have set the stage a bit,  what are some metrics you can obtain.

1. Tools are Essential -  The tools used can be simple to advanced. The key here is to have mechanisms to collect and integrate into other enterprise solutions. I've seen Excel and Word used to manage EA with a great deal of success but also with COTS based solutions as well. The key is to do what is right for your situation. Your tools should integrate into key repositories such as:
   • Application Portfolio Management
   • Business Process or Capability Repositories
   • Configuration Management and Ideally Service and Incident Management
   • Etc.
2. Architecture Decisions - It is a must to be able to document the decisions made. This needs to be a formal process in which all changes are documented and quantified. This is similar to change control but for the architecture design process rather than implementation.  But what does this mean exactly? It means that for each architecture problem you should have multiple potential architecture solution options. Each of these options have tradeoffs. Examples of data element that are included per architecture decision are:
   • Architecture Issue
   • Assumptions
   • Business Issue or Requirement
   • Potential Architecture Options
     • <#>
     • Solution Drivers
     • Risks and Implications
   • Decision
   • Implications of <#>
3. Aid on Mission Projects - Be humble and aid mission critical projects. This gives EA tangible metrics on your involvement in the success of a key business enable project. Similar and to a degree some of the same elements but at a higher level is to gather information on how you helped make the project successfully. To do this you need to quantify you architecture decisions. For Example, I formally recommended the following that was not in the current project designs:
   • Move to VM's and Blades - the result was lower electric and ventilation required in the data center, increased availably ratings of the applications, lowered the cost of disaster recovery and dramatically reduced infrastructure support staff. This resulted in a <x> million dollar cost savings.
4. Integration into Application Portfolio Management - Have an administration function that is able to monitor and track the health of the organization by taking snapshots of in time of the environment as a whole. By doing so you can track the gradual success of your EA efforts by aligning the work done on projects and IT optimization efforts.
5. Satisfaction Ratings - Solicit feedback whether it is good, bad and indifferent feedback. It should should be collected and acted upon. When you do a great job on that strategic project and the business sends you a happy gram find a way to put metrics on feedback to create satisfaction ratings. There should also be tools where people can submit anonymous comments and ratings on your performance. This can quantify the need for EA as well be demonstrating the need by the business and IT. Creditability is critical here and you must ensure to be honest with these. Even if there is a poor perception of your activities. Publish it no matter what.
6. Risk Management Ratings - Work with your Information Security and Risk Management teams to find ways to quantify how you are helping to build less risky and more secure architectures. Start simple and evolve if you do not currently have something to do this.

Second is to integrate into existing processes. You want to ensure that it isn't too intrusive to the process. Remember too much process is a bad thing. The key here is to gather key metrics from these processes. There are a ton of great metrics from process out there such as:

• ITIL or Microsoft Operations Framework (MOF) - There are some great books on the topic of ITIL metrics that you can check out. In regards to MOF there are a ton of out of the box metrics and KPI's that can be leveraged, see below:

       

• COBIT and SOX Processes - Likewise with these processes there are a ton of metrics that can be extracted.
• Correlate Process Metrics - Once you integrate into these process, either homegrown or acquired. You must now correlate these in a meaningful way. This takes a bit of creativity, however once you are finished it will pay off big. Just by performing this type of effort it can show immediate value to both the business and IT.
• Repeatability - Like stated in the previous post, you need to ensure that this process is a repeatable processes. By not doing this your metrics become circumstantial and invalid.

Lastly, communicate frequently. Surfacing this information is critical because what you want is awareness of your EA efforts. Overall perception is important to your organization. You should be viewed as a change agent in the organization. Tools that you can use to do so are:

1. Portals - Used for general purpose EA presence and communication. Also used for hosting of EA types of applications.
2. Forums - These are great for Q&A and keeping a dialog with the community.
3. Wiki's  - For project level activities wiki's provide yet another communication mechanism for EA's
4. Blogs - These should be used for personal opinions that document the bloggers perspective rather than a dialog like with Forums.
5. E-Mail - One way communications, be careful with this mechanism as you could be flagged as spam and ignored. I'm not a big fan of e-mail being used as the primary communication.

Each one has a specific purpose and should be leveraged for their strengths. Even though these mechanisms are "soft metrics" they can still provide you with valuable ways to quantify your efforts.

• Portals - Gather site visits and downloads of content to gauge EA interest and usage. By gathering stats from EA applications you can show a direct correlation with usage patterns.
• Forums - Measure end user interest in EA activities with user submission statistics. This is a great incentive mechanism to reward the architects in the community.  
• Wiki's  - Demonstrate your effectiveness on projects. You can correlate how significant your activities are on projects with tracking of tasks and submissions on Wiki's. This can be linked to architecture decisions and project planning tools as well.
• Blogs - Measure end user interest in EA activities with user submission statistics.

 

In summary, shown above are practical and realistic metrics you can use to quantify and qualify your EA efforts. Even though we didn't focus on the business directly, they benefits can be articulated in business terms as well. Once they see the successes you have achieved in IT, then and only then will you be a trusted partner to aid them directly on their efforts.

Like all EA organizations stat small and work in an iterative fashion. These activities are  rarely perfect out of the gate. However keep your eye on the future state and build or buy the tools that are needed to track these metrics.

Also keep your eyes on the organizational aspects such as:

1. Make it Public -  Ensure transparency in the process to prevent those "conspiracy theorist's" in the organization from damaging your metric gathering activities.
2. Identify Influential Stakeholders - Address their needs first, do not try to boil the ocean and provide generic metrics to address everyone. This just provides everyone with information that isn't really useful.
3. Identify Your Charter and Execute on it - Do not go beyond the scope of your EA charter. You can use the metrics acquired to expand your charter however.
4. Make it Tangible - Avoid selling your EA mission statement but rather how you are helping the community as a whole through what they already know.
5. Perspective based Communication - Since there are many ways to look at architecture, communicate in terms your audience understands. Additionally, you can communicate the metrics in different ways to varying roles as well.
6. Avoid "Selling" EA - Do not try to sell these metrics, merely post the good, bad and the ugly.

 

Tags: Enterprise Architecture Architecture Repositories