Is the pervasiveness of information making us stupid?

Homer's Brain

There is a great article from Nicholas Carr that is worth a read called "Is Google Making Us Stupid?". There is a similar article on the New York Times site as well called "Literacy Debate: Online, R U Really Reading?"

There is a common thread here, and that is information overload. Is this good, bad or indifferent? This is still subject to debate on the long term effects. Personally, I think that this is an issue. Information management will be the key in this digital age.



Creating a Enterprise Asset Roadmap Strategy


Recently I was asked to chime in on how to setup a global enterprise asset roadmap strategy. This was a fully loaded question and also a tricky one to answer. It is not an easy task as there is a number of forces at play and are extremely dynamic based on organizational culture, dynamics, structure and business objectives.

Lot of thoughts were communicated but I thought I would share my high level thoughts and considerations to keep in mind when developing an enterprise strategy. I am not going to go into the micro level detail here with templates and structures as this is an activity that is somewhat tailored to a specific customer and requires a lot of deliverables.

With an activity like this it is critical that you EA’s are pragmatic and focus on delivery as soon as possible to show results. The core principle that should be employed here should be:

Think strategically, act tactically

The majority of the challenges will not be technical in nature. But rather it will be primarily people oriented. This is not to say that the people are necessarily incompetent. It only means that the value proposition isn’t always obvious to all parties and there will be some level of education and persuasion on the EA’s part.

Some of these challenges include:

  • Adoption – This factor accounts for the majority of the issues that you will face when driving out a strategy. For most enterprises there are a number of people based factors that include:
    • Poor Perception – or lack of willingness to understand value proposition. There have been some great studies around this from Gartner and Forrester.
    • Understanding or Training – Coupled with perception, this factor hinders adoption due to the lack of understanding on why this activity should be performed
    • Incentive – Most employees in enterprises are not incented to do these activities. So if they are not incented, they will not do it. This does not always happen but can be used as a general rule of thumb.
  • Information – Many of the challenges of doing a current to future state architecture is the lack of information to do so. This problem needs to be solved to effectively figure out where an organization should go. The point here is that the future is always in motion. I recommend iterative strategies to develop “Transition State Architectures”. These are architectures that lend themselves to a set of principles defined for where they want to take a solution of capability. By delivering in an iterative way they don’t boil the ocean and are able to course correct if needed.
  • Tools – To be effective tools enterprises really need tools that empower the process and deliver critical information that empowers architects and developers.
    • The challenges is that many of the EA tools are intrusive and require a great deal of training. They also often require users to learn how they do things that may or may not be aligned with how development in that enterprise has been done in the past.
    • Most of these are proprietary even though they have plug-ins to extend
    • These tools are also high cost which enterprises starting out EA practices struggle with

From a tooling perspective, it should support the first two challenges. We have one orchestration of technologies that aids in this called the Enterprise Architecture Toolkit. It by no means solves all these challenges but does provide a pragmatic way of addressing these areas by focusing on automating and enriching the solution architecture development process. As mentioned before on my blog, it is a solution accelerator for supporting the architecture process within mid to large size enterprises. The EATK includes both architecture guidance and supporting code base to run the toolkit.

The key scenarios support architectural strategy with the following scenarios:

  1. Describing an Architecture with Current Tools
  2. Building a Collaborative Solution Architecture Design
  3. Extend Architecture Meta-Data into the Visio Modeling Environment
  4. Deriving to an Architecture with a series of Architecture Decisions
  5. Architecture Management
    1. Understanding Architecture Policy
    2. Managing an Architecture Life Cycle
  6. Navigate and Explore Approved IT Patterns
  7. Navigate and Explore Existing IT Architectures
  8. Obtaining the information for IT Strategy Management
  9. Determining the Total Cost of Ownership of an Architecture
  10. Manage and publishing of Principles, Policies and Standards

Keep in mind that this effort requires a great deal of work. There needs to be established:

  • Organizational Structures
  • Operating Models
  • Incentives
  • Definitions for Success Criteria
  • Savvy resource that can handle political maneuvering
  • New range of Architecture Operating Models
  • A great deal of Facilitation to help IT / Business / Operations work optimally together

Having clearly defined engagement and operating model should enable your organization to have a repeatable process for making decisions and delivering on artifacts at the right level of quality and consistency. 

Can you Easily Compare EA Frameworks?

Mike Walker's Blog: Comparing Apples and Oranges

Have you ever tried to compare EA frameworks? How do you compare and are all frameworks the same. The reader digest version of the answer is: No… Not all frameworks are the same but rather have there own definitions of what they are to deliver.

I have in the past and I have found it very challenging because it is a bit like comparing apples and oranges. When I talk to customers and folks internally about EA frameworks there is a great deal of confusion with current comparisons found online. Below is a common example:

Mike Walker's Blog: Comparing EA Frameworks


This comparison  really doesn’t tell us much detail. Although there is a whitepaper called A Comparison of the Top Four Enterprise-Architecture Methodologies on the MSDN EA Architecture Center we have the same issue with comparing these framework with the same base criteria:

Mike Walker's Blog: Comparing EA Frameworks Roger Sessions EA Compare

This isn’t to say these don’t provide value, they do from a macro level. However, the real challenge here is that these frameworks are fundamentally trying to solve different problems all together.

I see that there are two major types of frameworks:

  • General Purpose Frameworks – What sets these types of frameworks apart from others is that they are trying to solve the broader problem the enterprises are having. These frameworks do so by being agnostic to any specific implementation. They have no specific business drivers (enterprise specific) but rather are capability based. These frameworks are generally driven by industry consortia such as Open Group.
  • Domain Specific Frameworks – Frameworks that are derived from an EA effort are refereed to as Domain Specific. These frameworks were derived with a predefined set of business concerns in mind because they originated from an EA office or process improvement effort in a government or an enterprise. Largely these frameworks are driven by government agencies such as the US government or other geographies.

So how does the actual frameworks fit into these buckets.

General Purpose Framework Domain Specific Framework
Zachman MODAF

Should you eliminate one of these types form your efforts? Absolutely not. These frameworks have very specific value propositions. But we first need to know how they are fundamentally different.

Mike Walker's Blog: Comparing EA Frameworks

As shown above there are two basic characteristics. We look at the allowable level of customization vs. prescriptive guidance. These frameworks slide down the continuum from the level and ability to customize to the level of prescriptive guidance. The general purpose framework has a greater level of flexibility as it is attempting to solve all problems. Whereas the Domain Specific Framework is solving the problem with a series of predefined set of forces and attributes.

For example: A government based framework such as FEAF / TEAF / FEAF will be based on the specific government based regulatory laws (region based), a set of operating and organizational models that is specific to that agency. These will drive out the process and artifacts required to fulfil these base business drivers.

So what do you get with these different types of frameworks? With these two classifications of frameworks there are a set of artifacts, methods and tools that are derived. These are derived on the the base problem sets defined earlier. Since these are derived, the outputs can be very different. See below:

General Purpose Frameworks:

  • Defines an open and consistent definition of terminology through taxonomies and ontology.
  • Agnostic to organizational structure
  • Low level process agnostic
    • SDLC
    • PMO
    • Service Management
    • etc.
  • Very configurable to enterprises

Domain Specific Frameworks:

  • Prescriptive guidance for:
    • Organizational structures
    • Processes
    • Artifacts
  • Usually deliver lots of templates
  • Lots of real world examples

Is the comparison of EA Frameworks like comparing Apples and Oranges? Yes it is. When you compare these frameworks they should not be treated the same nor should be judged based on the same criteria. Rather they should be correlated with your specific requirements. 

19th Enterprise Architecture Practitioners Conference: Day 1 Highlights

For those who didn’t get the updates. Here is a summary of the activates at the Open Group Conference in Chicago.

The Open Group’s 19th Enterprise Architecture Practitioners Conference kicked off on Monday, July 21st in Chicago.  Industry leaders from near and far convened at the historic InterContinental Chicago Hotel to share their insights on the latest enterprise architecture trends, challenges and opportunities facing federal government organizations as well as global businesses.  Below, please find highlights from Day One.

Allen Brown, President and CEO, The Open Group, kicked off the Day One “Frameworks for Federated Architectures” plenary session with open remarks. Mr. Brown welcomed several hundred attendees from around the globe.

Following Mr. Brown’s opening remarks Wing Commander Shaun Harvey, Department Director, United Kingdom SAF/XCPA, delivered his presentation, “Architecting for Interoperability using Fit For Federation Criteria.” Wing Commander Harvey prefaced that much like complex, highly distributed businesses, the Department of Defense (DoD) is comprised of many interdependent components. These include the Air Force, Army, Navy, and Marines, each of which shares common integration and interoperation issues. While the DoD and the Air Force use Architecture Federation to help address integration, the Wing Commander explained the Air Force’s development of an Architecture Federation approach called “Fit For Federation” to specifically support interoperation.

Next, Marc Othersen, Senior Analyst, Forrester Research, delivered his presentation “Compliance Frameworks: The Foundation of IT-GRC.” According to Othersen, business imperatives, increased regulatory pressure, and customer demands are forcing many CIOs to adopt a structured, enterprise wide approach to deal with IT governance, risk, and compliance (GRC). Because IT GRC initiatives have traditionally been scattered across organizations without much coordination, many companies are looking for solutions that can help them create a unified approach to managing information risk and IT compliance requirements while ensuring good governance at the same time. Marc outlined Forrester’s view on IT GRC and gave recommendations for developing a robust IT GRC program.
To access additional information on Marc’s presentation, including a free report from Forrester, entitled “Defining IT GRC”, please visit:

Ron Schuldt, Senior Staff Systems Architect, Lockheed Martin Enterprise Business Services
, next presented on “An Open Group Standard for Building Your Controlled Vocabulary.” Mr. Schuldt began his address by explaining that TOGAF™ does a great job of identifying the processes necessary for defining an enterprise architecture, but it does not assure “Boundaryless Information Flow” across organizations. The Open Group standard that provides the foundation framework for a controlled vocabulary, known as the Universal Data Element Framework (UDEF) is part of the solution, argued Schuldt. His presentation provided a detailed demonstration on UDEF and highlighted the role of this critical standard within the enterprise. For more information on the UDEF standard, visit:
An in-depth UDEF Training is open to all conference attendees on Wednesday, July 23rd at 9:00am.
The day’s last plenary presentation, “Standardize Architecture Delivery in a Federated Architecture using TOGAF,” was given by Peter Van Hoof, Principal Enterprise Architect, Sasol, South Africa. Sasol, South Africa’s largest industrial company, has a strongly entrenched federated business model and utilizes a deeply embedded business project methodology across its many diverse business units, called the Business Development and Implementation Model (BD&IM). Mr. Van Hoof’s presentation covered how Sasol aligned TOGAF with the BD&IM – a great example of how to standardize architecture delivery in a federated architecture environment using TOGAF.
Kicking off the afternoon’s Government Enterprise Architecture Track was Robert Weisman, Partner & Executive Consultant, Global Enterprise Architecture Practice Leader, CGI, with “TOGAF Case Studies in Government.” Mr. Weisman highlighted several applications of TOGAF in selected US State and Canadian Federal Government engagements. The presentation provided recommendations for future use of TOGAF within a government environment and also discussed how TOGAF works in conjunction with other EA frameworks, including Zachman, EA Tool, Australian Government Outcome Based Planning and Australian Government Architecture.

In the TOGAF Track, Matt Vandenbush, Enterprise Architect, Brady Corporation, presented a case study “Preparing the Enterprise for a Successful Architecture Program Based on TOFAF.” Mr. Vandenbush began his presentation with a poignant statement, “Almost half of EA groups are dissolved within two years and many more do not meet stakeholder expectations.” This is more often the outcome of poor internal advocacy- architects within their organizations need to prove the value of EA as a tool for making better decisions; and TOGAF has served as Brady Corporation’s guide to achieve this level of success. Mr. Vandenbush made recommendations on the three most important activities to make EA matter within any organization: getting your governance processes under control; prepare to use the TOGAF architecture development method (ADM); and focus on “delivery”.

Later in the Government Enterprise Architecture Track, Eduardo Castro, Architect, Grupo Asesor en Informatica, Costa Rica, presented on “Digital Government Strategy in Costa Rica.” He covered the strategy followed by Costa Rica to implement a massive EA initiative in order to bring better services to the public institutions, providers and citizens.
In the SOA Track, Pinaki Ghosh, Lead Architect Specialist, The Dow Chemical Company, delivered a lively presentation on “Developing Enterprise Business Object Libraries to Support SOA.” Mr. Ghosh began his session arguing that the main competitive advantage in information architecture comes down to a well constructed information footprint model within an EA framework, such as TOGAF, Zachman or DoDAF. During the transition from legacy architecture to SOA, however, one of the critical things most companies neglect is the preparation of an Enterprise Object Library. Such a library contains both business and IT objects categorized by international standards, unique artifact numbers and database identities. Pinaki’s presentation delved into The Dow Chemical Company’s use of a business object library to better align IT services with the business.

Chang Peng, Enterprise Architect, MoneyGram International, closed out Day One’s EA Best Practice Management Track with his presentation “Enterprise Architecture in Support of Business Strategy.” The goal of Mr. Peng’s presentation was to extend enterprise architecture beyond the IT walls to support corporate business strategy. Chang’s presentation demonstrated how MoneyGram International re-aligned their traditional EA model to encompass deep rooted business logic and link with several tangible business strategies. As a result “enterprise architecture” is now a part of the common vocabulary among MoneyGram’s senior executive management team.


Microsoft Strategic Architect Forum 2008

For those interested, the 2008 Microsoft Strategic Architect Forum (SAF) will happen again this year. Each year my team organizes this conference so that top architects from around the world can get together to collaborate on key challenges in the industry. This year, it will be held in downtown San Francisco instead of back at Redmond (like all other years). The tone of the conference will still be the same with a great line up of speakers and round table discussions.

What is SAF?

I have blogged about this before you can find the post here. You can get the slides and recorded video from last years SAF.

SAF 2007 Recorded Sessions

SAF is Microsoft’s premier gathering of 350 strategic architects and other key influencers from enterprises, ISVs, and start-ups from around the globe.  Each year, SAF is an invigorating and lively event, with key technology leaders from across Microsoft sharing their vision with customers and listening closely to their business needs. 

SAF, which follows the Microsoft Professional Developers Conference (PDC) by a month, is designed to be complimentary to the PDC – SAF will dig into the strategic architectural issues posed by bringing together the various products and technologies detailed at the PDC into the solutions our customers care about most. 

More information will be forth coming.

Seven Cloud-Computing Security Risks

Mike Walker's Blog - Cloud Computing

In a recent article on Network World they highlight security issues with the cloud. Jon Brodkin extracts his thoughts from a Gartner report titled “Assessing the Security Risks of Cloud Computing.” If you had seen my last post on Challenges moving to the Cloud you can see many synergies with our thoughts.

Key Nuggets in the article include:

  • Gartner defines as a type of computing in which “massively scalable IT-enabled capabilities are delivered ‘as a service’ to external customers using Internet technologies.”
  • Ask questions related to the qualifications of policy makers, architects, coders and operators; risk-control processes and technical mechanisms; and the level of testing that’s been done to verify that service and control processes are functioning as intended, and that vendors can identify unanticipated vulnerabilities.
  • Customers are ultimately responsible for the security and integrity of their own data, even when it is held by a service provider.
  • Even if you don’t know where your data is, a cloud provider should tell you what will happen to your data and service in case of a disaster. “Any offering that does not replicate the data and application infrastructure across multiple sites is vulnerable to a total failure,” Gartner says
  • Ideally, your cloud computing provider will never go broke or get acquired and swallowed up by a larger company. But you must be sure your data will remain available even after such an event.

There is an emerging trend with the challenges associated with Cloud based computing, it is less about the technology rather more about the business and operational sides of solution development. Even here when we talk about security there is very little mention about security protocols, encryption, authentication providers and so on.

Just like with any other architectural decision, there is a trade-off when moving your applications/services outside the firewall.  Enterprise should take the lessons learned from the previous models like B2B, ASP or Managed Services. These previous methods ran into the same challenges and I would bet that there are some lessons that can be learned by digging up the past.

For more see:

Open Group SOA Ontology

The Open Group has recently released a draft version of a SOA ontology. They have been developing a formal ontology for SOA for some time now. You can find the ontology described in OWL-DL also. This should give the ontology a more complete level of description.

Open Group explains the benefits as:

1. It defines the concepts, terminology and semantics of SOA in both business and technical
terms, in order to:

  • Create a foundation for further work in domain-specific areas,
  • Enable communications between business and technical people,
  • Enhance the understanding of SOA concepts in the business and technical
    communities, and
  • Provide a means to state problems and opportunities clearly and unambiguously
    to promote mutual understanding.

2. It potentially contributes to model-driven SOA implementation. The ontology is designed for use by:

  • Business people, to give them a deeper understanding of SOA, and its use in the
  • Architects, as metadata for architectural artifacts; and
  • Architecture methodologists, as a component of SOA metamodels.

The full draft can be found here:

Tags: Enterprise Architecture