Good High-Level Enterprise Architecture Video

I ran across a really good high-level Enterprise Architecture video last week and thought I would share. It’s brought to us by ArchimateMusings blog. This looks to be a video that his company created to articulate EA’s overall function and value proposition. Here is the description of the video:

This animation shows the role of Enterprise Architecture starting from the perspective of a business user. That user has understandable wishes and requests, and the IT decisions made for him all make sense. But the result of all business users doing this independently is a ‘hair ball architecture’. The role of Enterprise Architecture to prevent this from happening is illustrated.

The video was created by T36 (http:// in Maastricht, The Netherlands for APG Asset Management ( T36 created the story board from interviews with APG AM’s Lead Architect, Gerben Wierda. The video is owned by APG and it may move to an APG-owned channel later.

I wanted to share this with everyone because I think it’s important for EA’s to have a rich set of visuals, examples and media to facilitate the continous education process with our customers. While the video didn’t speak of strategy and business enablement directly, I do think this is a good primer or overview of some key value propositions for EA.



Technology Architecture Questions for Vendors

As time goes by architects are reviewing less custom / “home grown” solutions and looking at commercial off the shelf (COTS), platforms or cloud based solutions. I thought I would share with you a vendor architecture question template that I have used in the past to fast track my understanding.

Keep in mind that this isn’t an RFI / RFP type template. It can be used to augment one but isn’t the full view, just technology. I try to work with PMO, procurement and others to include this to the RFI / RFP process.For the sake of this post I will assume that’s not the case. 

I use this template as a first pass with the vendor. It serves as a base understanding so I can then ask my level two and three questions of the vendor. Here is the process in which I use:

  1. Modify for the solution – Review the template for any modifications. usually there are tweaks that need to be made based on the type of problem or solution that is needed.
  2. Send to vendor – Send with instructions that it needs to be returned in a timely manner and decisions will be made based on the quality and accuracy of the information. 
  3. Distillation – I use the information to categorize how well the vendor’s technology:
    1. Aligns the companies policies and standards
    2. If they are instantly disqualified for some reason
    3. If it meets the non-functionals / quality attributes of the requested solution 
  4. Compile additional questions – The vendor solutions that make it will most certainly have additional questions that will be needed to be answered. Compile the extended questions and send to the vendor.
  5. Deep dive workshop – I like to do a deep dive workshop with the vendor so they can expand on their responses and provide a forum for EA to probe more into the solution. 
Below you will find the questions. Some of the questions are a little dated and need updating. I’ve been using flavors of this for years, but I think you will find that directionally useful. 

Architecture Domain




What architecture style used to build this application? (ex: Cloud, SOA, SaaS, N-Tier, client server, etc.)


Is there a separation of concerns in the architecture to the effect that solution components have very specific bounds and are applied at the right layers?


What documentation can be provided?(Ex: ERD application API’s, UML diagrams of objects, business process models)


Does the solution support internationalization and localization?


Define the solution roadmap with product version cycles, expected point and major releases of the current version.


Is there usage of proprietary technologies?


Application / Logical

In what languages is the application built?  This includes business logic and presentation tiers.


Has the application been ported into other languages?


Are there a blend of multiple languages and/or versions of languages in you solution?


Is there a mixture of language interpreters?


Is the application customizable? If the application is customizable, what methods, languages and tools are needed to customize? Are these tools bundled in the solution?


Is the source code provided with the solution?


Are there “out of the box adapters”, plug-ins or accelerators provided as productized and supported by the vendor?


Is there a cloud based offering? If so, what service models (IaaS, PaaS, SaaS) and deployment models (Private or Public) are supported?


What client models are supported:

 1. Mobile – What platforms, application type (app vs. web based) and the limitations

 2. Browser – What browsers are supported and what standards are used (ex: HTML 5)

 3. Thick Client – What OS platforms are supported?


Is there a configurable business rules and or workflow engine included?


Are there business process or workflow capabilities built into the solution? If so, what standards does it use?


Are there any open source used in your solution?


How much of the logic is hard coded vs. being data driven or configurable?



Do the solution support integration with its processes and information?


At what level and how deep is integration supported?


Explain how functionality can be extended in the solution


Describe the various protocols supported by the solution. Indicate required, optional and major non-supported protocols.


Describe communication ports and ability to move across the enterprise and outside the company firewall.


Is there support for Enterprise Service Bus (ESB) or middleware technologies?


If ESB or middleware technologies are supported, how is the solution configured to fit within a services framework?


Is the integration supported by services? If so, what types of services? (ex: Web Services, EJB, .Net Remoting, Queues, etc.)


How are the services implemented?


What service standards are used? (Web Services over HTTP, SOAP, REST, etc.)


What services directories (ex: UDDI) can the solution hook into?


Does the solution provide or receive bulk transactions or data feeds?


Does the solution wrap the database with a service or does the solution access the database directly?


How does the solution support synchronous and asynchronous transactions?


Does the solution have publish/subscribe capabilities?


Are there integration adapters that are provided? If so, identify.



OS Platforms


What are all the supported Operating System (OS) platforms and their versions across the solution?


Describe the OS platforms and their configurations at all tiers of the solution.


Has the solution been tested and/or certified with new OS platforms or emerging OS platforms that are in planned release within the year?


If there are multiple OS platforms available (that compete), provide the recommended OS platform(s) with pros and cons contrasted by your solution set.


Are there recommended platform recommendations based on size of the organization and/or the size of the solution? If so describe the recommendations.


Application Platforms


Describe the application platforms that are required in the solution. (ex: Apache, IIS, BizTalk, WebSphere, etc.)


If multiple database platforms are supported, what are the preferred DB platform(s)?



What is the solution licensing model?


What client licensing is required for each end user or desktop?


What is the server licensing model? (ex: per CPU, per CAL, per Core, etc.)


Are there any third party licenses required?



What class of hardware is recommended across the tiers of the solution? (ex: processor, disk, memory, etc.)


Provide a profile of recommended server counts and configurations.


Is virtualization supported? If so, by which vendors?


Provide example physical topologies of the solution.


What is the scaling model for the architecture (Scale-Up / Scale-Out )


Data Communications

Are there any network requirements for this solution?


Are there any solution limitations with implementing network segmentation?


Are there any solution limitations with implementing multiple DMZ tiers?


Are there any solution limitations with implementing VLAN’s?


Are there any solution limitations with implementing network appliances such as SSL / XML acceleration or network load balancing?


SaaS Solutions

Is there a solution hosting model? If so, define.


Is a cloud platform provided for optional development or integration?


Is the solution hosted on a third party platform? (ex: Amazon or MSFT?)


What is the solutions connectivity to the internet or to internal systems?


Define the solution inbound and outbound traffic.


Is multi-tenancy supported?


What level of business continuity and disaster recovery supported?


Performance and Scalability

Is load balancing supported and implemented in the solution?


At what level is load balancing supported? (ex: application and/or at the network level)


Describe how high availability is supported.


If available, provide a performance and/or stress test report.


Describe the number of transactions per hour that the solution can handle with the recommended solution implementation.


Describe the number of concurrent user sessions that the solution can handle with the recommended solution implementation.


What is the recommended scaling model? Scale up or out?


What factors determine hardware, OS, database or other system component upgrades?


Describe the algorithm or guidance that you use to determine the solutions configuration and scaling model.


Describe your systems capabilities for automated fail-over and/or error detection and prevention



What is the authentication model?


What is the authorization model?


Does the solution support Single Sign On? If so, is customization required?


Can the security be externalized into an enterprise identity store such as Microsoft Active Directory?


Are trust boundaries defined with users that are authenticated across those trust boundaries.


If security is custom and internal to the system, can the solution support strong passwords?


Is there security API’s for application level integration?


What auditing mechanisms are available from within the tool?


If externalization of authentication and authorization is unavailable can identities be provisioned and de-provisioned? If so, elaborate?


How are transaction secured?


What protocols are used to secure the solution?


Are data or message level transactions supported? (ex: ws-security)


Is federated identity supported?


What level of hardening is supported on the platforms and protocols/ports?


Is there unsecured data at rest along the process chain?



What end-user training options are available and at what cost?


What administration training options are available and at what cost?


What application development training options are available and at what cost?



Is an ERD available for the solution?


Is a data dictionary for the solution available and if so what is the format and what metadata does it include?


What databases and versions are supported by the solution?


What database versions have been certified and/or tested?


If multiple databases are supported what is the preferred database?


How is access to the database achieved from the application?


How is access to the database achieved from external applications?


Are there specific database access components or drivers required at any tier in the solution? (ex: client tier)


Identify all the locations in the solution where data may be kept. This can include flat files, cookies, XML files, access databases, etc.


Is referential integrity handled at the application, services, database or not implemented?


What is the typical size, number of transactions and complexity of the database compared to the requirements given by our company?


Under what conditions can the database significantly expand? (ex: increase in customers, employees, assets, transactions, etc.)


What is the largest database implementation that you currently support?


Provide a list of all the database platforms you support.


Does the solution have special fault tolerance mechanisms?


Will the solution support native database fault tolerance mechanisms?


Does the solution allow for SSIS or ETL solution integration?


Are there any special considerations for backup and recovery of the solution?


Are there any batch processing events that occur within the application?


Is the supported solution database schema modifiable?



What is the delay before the solution supports a next release of dependent platform such as OS, database, Web Server, etc.


Describe the instrumentation included in the solution that allows for the health and performance of the application to be monitored.


Is there a defined support model based on technology or platform selection?


How often are new versions released?


How often are patches released?


What is the support model for the solution in relation to the co-existence with OS patch releases?



If you decide to use these questions as a starting point for your evaluations, please tell me about it as I would love to hear how you have changed the questions based on the solutions you are evaluating. 


TOGAF Templates

Possibly one of the most common questions I get with regards to TOGAF is finding a good sample set of templates. Luckily the Open Group has a set that you can download that is quite extensive. Personally they aren’t the prettiest to look at but it will most certainly be an accelerant to leveraging TOGAF.

See below for the links:

Below you will find a listing of some of the templates included.


  • Application Architecture: Applications Portfolio Catalog, Interface Catalog
  • Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
  • Data Architecture: Data Entity-Data Component Catalog
  • Preliminary: Principles Catalog
  • Requirements: Requirements Catalog
  • Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog

Core Diagrams

  • Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
  • Architecture Vision: Solution Concept Diagram, Value Chain Diagram
  • Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
  • Data Architecture: Class Diagram, Data Dissemination Diagram
  • Opportunities and Solutions: Benefits Diagram, Project Context Diagram
  • Technology Architecture: Environments & Location Diagram, Platform Decomposition Diagram

Extension Diagrams

  • Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram


  • Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
  • Architecture Vision: Stakeholder Map Matrix
  • Business Architecture: Actor Role Matrix, Business Interaction Matrix
  • Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
  • Technology Architecture: System-Technology Matrix

Example deliverables are as follows

  • Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
  • Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
  • Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
  • Phase E: Implementation and Migration Plan, Transition Architecture
  • Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model


The Best Debater May Not Be the Best Enterprise Architect

Last week I read a great article from the Harvard Business Review blog entitled “The Best Debater May Not Be the Best Leader” that I found to be true for leaders but also very true for Enterprise Architects. When I read this article I reflected a bit on the meetings, conversations and get togethers with Architects over the years. One common thread among that reflection is that there is quite a bit of debate. This debate often ends in a stalemate between the parties. For the debates that center around pure technology it’s even worse. Don’t bring in Java vs. .Net or iPhone vs. Android, the debate turns into conflict. 

I believe healthy debate and constructive conflict is actually very useful. Challenging ideas and the status quo is what I believe EA should be doing. However there is an approach that should and shouldn’t be taken. 

From HBR:

But having worked with hundreds of senior leaders over the years, I’m not convinced that debating skill is a good indicator of leadership potential. In fact, from my experience, the ability and willingness to debate is often a leadership liability.

This is not to say that debating is unimportant. Being a good debater requires a mastery of facts and issues, and the ability to put them together in a coherent and convincing manner. It also calls for rapid adaptation of arguments and being fast on your feet, which is a great skill for managers who need to make quick but informed decisions.


If the bolded text doesn’t say EA I don’t know what else does. EA’s are unique leaders. They often don’t have direct influence over the organization. EA’s lead through influence and must win over the hearts and minds of their customers. If that is true, it is critical that EA’s don’t alienate their customers through the process. 

Personally this has been tricky for myself as well. I love a good debate. I observed sometime back that my passion was getting in the way of progress. Being so wrapped up in what might be philosophy or what had worked at another company actually got in the way. It was hindering my ability to move the business forward. I had the absolute best intentions and the debate wasn’t centered around why I am right but rather my passion for moving the business forward. But the approach was all wrong.

This article gets to the heart to what I had to learn the hard way. Believe me, I have the scars to prove it. 

Similar to what I learned HBR goes through a simple mental context change. A different way of approaching the debate. See below:

Effective leaders spend much more time listening, probing, exploring, and facilitating discussion than they do debating. In fact, debating the issues, trying to score points, and focusing on “winning” arguments is usually a recipe for shutting down dialogue. Each side ends up becoming more attached to their position and it becomes harder to find middle ground.


This hits the nail on the head. Those four aspects are key:

  1. Listening – This is very important, maybe even the most important of the four here. There are two reasons for this. First, it is easy for the debater to “tune out” or doesn’t pick up on valuable information because we are so focused on our side of the debate. This then turns into debate for debate sake instead of focusing at the problem at hand. Second, When the other person(s) in the debate feel like you are listening and empathizing with their position they are more willing to be persuaded and get past just debating but moving forward to solve the actual problem. 
  2. Probing (Asking Questions) – This is linked to my second point above. If the person(s) you are debating with understands that this isn’t personal to you and you actually want to hear their position and move forward it helps everyone. 
  3. Exploring – Problems that EA’s try to solve are often complex and are broad. Exploring all avenues and perspectives are important to have a fully rounded solution to any given problem. Open your mind to all other aspects of the problem. You will be surprised what you may of missed and how the solution evolves. 
  4. Facilitating – I find myself doing this all the time. Since I primarily try to stick to 1 – 3 above, often times others don’t. EA’s can take this mental framework and apply it to meetings to shepard the organization in the right direction. This again shows the EA as an enabler thus wins credibility with the customer(s).

I think HBR ended the post well, I couldn’t say it any better.

But in organizations, debating skills — such as presenting logical arguments, responding to questions, and challenging opposing views — should instead be leveraged in the service of exploration and engagement. This means that the objective should not be to win, but to bring out the nuances of the issue. This way, you’ll reach a better conclusion that people will be confident in, because they’ve heard the various sides. 

A Strong Personal Brand can Help EAs Become More Effective


One of the most important lessons that I’ve learned from my Microsoft
career was the importance of a personal brand. It helped me tremendously while
I was at the company. It both served me well inside and outside the company as
well. It allowed me to connect my ideas with people even if they didn’t know me
personally. This was important because it got me in the door to conversations I
wouldn’t normally have, get past that initial barrier in initial conversations
and learnings about who I am and what I’m about out of the way and we could
focus on problems we needed to solve.

There are many definitions but I thought I would fall back
to a Wikipedia on the definition of personal branding:

Personal branding is, for some people, a description of the
process whereby people and their careers are marked as brands. It has been
noted that while previous self-help management techniques were about
self-improvement, the personal branding concept suggests instead that success
comes from self-packaging. Further defined as the creation of an asset that
pertains to a particular person or individual; this includes but is not limited
to the body, clothing, appearance and knowledge contained within, leading to an
indelible impression that is uniquely distinguishable.


As an Enterprise Architect, this is a very important
concept. Much of the EA formula to achieving results is through trust and
credibility. Achieving  trust and
credibility isn’t like a onetime event similar to selecting an EA Framework,
but a complex people oriented and ongoing activity.

Simply put, the ability to personally brand yourself allows
you to stand out in the crowd, get into forums you normally wouldn’t get into, presented
with new opportunities and the opportunities to have your thought leadership visible
across a company or industry. 


Some helpful resources for personal branding can be found:

Slow Down to Speed up EA Results


Speed to market has been a factor in architecture since the
day I started as an architect. Every time I have priortized getting a solution in as fast as possible it has always come back to bite me. Funny enough, I see this behavior today. Whether
it is a strategy or a tactical initiative the customer always wants it faster
with more. EA’s are both blessed and cursed in that they are very smart and
have lots of great solutions but that is sometimes abused as being perceived as
having the magical powers of making things faster without breaking anything. EA’s
can’t defy physics. I know that’s not what anyone wants to hear but it’s the
state of affairs.

Sometimes you have to
slow down in order to truly speed up.

You might be thinking, “Mike, you have completely lost it.
That doesn’t make much sense” On the surface you are right, but the irony it is

What does this mean, exactly?

The irony here is that going far is that just done by going
fast but consistently. Speed and consistency are two separate things, and one
more often than not is indicative of success. To be successful, you have shown

So the questions then comes up to two factors: Speed to
Market vs. Speed to Value

  • Speed to
    – With speed to market the center of attention is on how fast we can
    deliver results. Often times with just speed execution can be clumsy or even reckless.
    The exact reason why this is the case is because the primary driver is speed and
    not necessarily value, quality and consistency.
  • Speed to
    – While speed is important to generating value and addressing time sensitive
    business factors, the fact remains that value is generated from predictable and
    repeatable results in order to do this speed isn’t the primary factor. What
    this results in is slowing down to ensure that value is created.

As an EA, what is most important? Some will say one versus
the other but I believe EA’s real value is to focus on the Speed to Value. We
will always have edge cases where we do the Speed to Market.  But using the 80/20 rule the real value for EA’s
is through Speed to Value.

To put this into context, let’s use a runner analogy. What
determines your value? Winning a race does. But to do that there is a discipline
that needs to happen. Courtesy of (,
here are main factors to running faster:

  • increasing stride length
  • increasing stride frequency
  • improving lactacte threshold and VO2 max
  • being able to spend more time running at your fastest possible speed

Bolded are the key words that highlight a method to
achieving results. There is actually a lot of science behind being the fastest.
What this tells us is that you don’t win a marathon without a method to
achieving results. This is through a repeatable and predictable method.

So let’s bring it back home to our daily lives as Enterprise
Architects.  EA’s can deal with an
amazing amount of complexity on a daily basis. To come up with any strategy or
solution, we need to properly understand that complexity and predict the risk
of what a change would do to that complexity.

When you introduce speed into the mix with complexity and
risk it can be a dicey situation.

When we don't slow down, we run the risk of spending time (and
funds) doing the following:

  • May not get the support needed by alienating  a member of the team by due to your pace and
    the pace of the member being different
  • Go so fast we don’t acquire or gloss over the information
    needed to make an informed decision
  • Run the risk of reacting to symptoms of the
    problem and not the actual problem


So instead of focusing on speed, focus on:

  • A method to ensuring predicable results
  • Continuous learning through exploration of ideas
    and research
  • Collaboration with other smart people whether
    they be EA’s or not
  • Common way of leveraging the information
  • Scale your work by taking very specific problems
    and creating generic patterns for reuse and acceleration of future decisions

 So be a change agent in your company and highlight why speed
isn’t the primary driver behind value!

US Navy Updates it’s Enterprise Architecture Framework to 4.0

The United States Navy released it’s department of Defense and the Navy (DON) Enterprise Architecture Framework on 4.0.

US Navy DON Enterprise Architecture Fwk 4

Like with all other US government agencies they are federally mandated to have enterprise architecture (EA) established to support their IT strategies and to capitalize on their vast technological assets and make sound decisions about investments in new technology. 

Below is a snapshot of the EA method for Supporting IT Business Transformation portion of the framework:

US Navy DON Enterprise Architecture Method 4


The DON Chief Information Officer (CIO) is leading the effort to design and develop a single DON EA, using a strategy that federates with external partners and incorporates an integrated, coordinated, flexible and long-term strategically focused approach. The DON EA describes the processes, information flows, solutions, data descriptions, technical infrastructure and standards that are integrated to achieve current and future DON strategic goals and objectives.

The DON EA assists decision makers in the execution of major decision processes such as the Defense Acquisition System, Planning, Programming, Budgeting and Execution, and the Joint Capabilities Integration and Development System.

Interestingly enough, since the release of the Global Information Grid (GIG) Federation Strategy in August 2007, the DON CIO has tailored the federated approach in developing and managing the DON EA. The DON EA will federate with DoD and other external partners.

For more information: