Post 21: More on Transformation Success

MEGA, a company well-known for its web-based EA tool set, made a recent blog post concerning transformation through the methodology of business capability evolution. The premise is that business capability evolution as the motivational replacement for projects. The idea in the MEGA article is that the “Business” has goals. Everyone has goals, in fact. Business capability evolution is a strategic execution vehicle to achievement and assurance that the outcome matches the business strategy and goals. How?

The post suggests that all too often a goal to acquire a new capability, say predictive analytics, quickly digresses into a technological solution implementation, like upgrading the ERP or installing BI. The failure in this scenario comes when projects are focused on implementing the technology and ignoring the rest of the architecture, lets say the people and process involved. So while the technology is ultimately important, it’s probably the least important because without the other two elements, the tool will be difficult to extract value from.

The argument made is that attention is all too often repositioned from the goal of acquiring a new business capability onto a mere tactic of the capability, in this case the technical installation of the tool. In other words, we’ve lost sight of the original goal. What has to be done to correct this is argued that one should be procuring technology to enable the evolution or realization of the given business capability, not only technology. The results suggest that organizations fund business capability evolution are more likely to reduce failed project implementations.

The article’s intentions are good enough but I’ll admit I was hoping for a more dramatic idea. I’m sure some companies and CIOs articulate IT strategy this way but I hope most organizations who recognize the need for EA are more advanced in their IT engagement articulation than just focusing on a tool implementation. After all, shouldn’t there be functional requirements, use cases, and actual business objectives behind the goals? On the other hand, if IT is attempting to innovate and prepare the technological capabilities with the “build it and they will come” mentality, there’s a real risk the business won’t be ready for the transformation and ROI will be difficult to extract.

Daniel Hebda. To Succeed in Transformation, Stop Funding Projects!


Post 20: Where Does Enterprise Transformation Begin?

I was reading this article on concerning Enterprise Transformation where the question was posed:  “how to begin process of enterprise transformation.” That is, “Do we start with the business first and then address technology or the other way around?”  

Okay. Well, the author, Edmead, answers the question with a fair enough generalization:  “business and IT are two sides of the same coin.  You should not transform one without considering the impact on the other.”

Edmead goes on to talk about the need for change in organizations. You know the drill:  change is normal, a way of life, required to survive, etc… However, the premise made is that “Enterprise transformation” deals with “the fundamental organizational change that impacts how its core business is conducted.”

I think it’s great that the author uses TOGAF and its architecture development method (ADM) as an instrument to facilitate transformation.

togaf adm
Figure 1. TOGAF ADM.

Since the ADM is iterative, Edmead argues that it’s particularly useful for working on parts of the architecture that you know while leaving other questions unanswered. This allows us to understand enough of the business strategy to begin to put a transformation path into play. In the next iteration, this business architecture can be evolved if necessary; meanwhile, an architecture team can begin to design the ideal information system and technology architecture concepts to support the target business requirements.

To sum up why Edmead thinks TOGAF helps answer the question of where to start, he emphasizes that TOGAF supports the concept of “target first” and “baseline first.” It means, we can begin the transformation initiative by evaluating the current state first or the future state. For optimum results, one has to identify the gaps between baseline and target in order to design a roadmap for transformation. That means we’ll eventually need both views, but the choice of where to begin is often a matter for architects and project managers to decide. In Edmead’s words: “If we know how we want the future state to look like, the we could begin with the target first and work our way back to the baseline. If we are not sure what we want the future state to look like, we could begin with the baseline and work our way to the target state.”

I’m pretty okay with what the author is sharing in this article overall and I like the simplification of TOGAF’s ADM. But overall I think the post is a little obscure and open-ended where business transformation is concerned. The truth is, real enterprise transformation is just not that simple and there is a wide space between business motivation that leads to needing an EA in the first place. How a business ultimately chooses to position an EA practice and framework like TOGAF varies widely. Often, business transformation like strategic differentiation, mergers and acquisitions are left in the hands of the executives and EA is brought in later to help rationalize the impacts of these business strategies on the IT architecture. In that sense, the author is right. Most of the time, however, EA is not creating Corporate and Business Strategy, it is instead responding to those needs and investments and helping to guide the transformation with the ideal IT engagement.

Mark Edmead. Do you begin an enterprise transformation with the business or with IT?

Post 19: BPM and the Customer Journey

In the past weeks the topic of Business Process Management (BPM) has been a focus in our EA team. I was reading a blog post about a customer experience technique known as the “Customer Journey.” The premise is that service-based organizations should be concerned with the experience of the customer. Traditional product manufacturing focuses on the experience with the end product. But when customers are involved in an experience that leads to a product purchase, the end-to-end experience can have a profound effect on the the purchase as well as the customer loyalty. Consider the example of Dell whose “build-to-order” web experience for customizing the computer system that best suits the buyer is more than just selecting from a catalog. How about the Apple Store which is like a big sandbox encouraging play.

The referenced blog highlights IKEA, where the experience begins with parking, to showroom, to pick-up. This is all fluid and connected. The customer might be delighted with the showroom, while highly annoyed with the self-service pick-up!

Borrowing the author’s BPM-like “Customer Journey” map, you see the example how to plot this:

Figure 1. Customer Journey Map. Peter Matthijssen,

Matthijssen suggests the technique is a must-have for our BPM/Lean toolkits. I could agree to this much. For EAs, it’s a great BPM-like view with swimlanes that focuses on the viewpoint of the customer experience. We could use this to consider weak areas in our capabilities and discuss with stakeholders how their business strategies are positioned to improve the experience. Keep in mind, the author suggests that some weak touch points are normal as such contrasts can actually improve the experience. Matthijssen refers to this as the “Pain-Pleasure-Gap” (PPG).

Peter Matthijssen,

Post 18: EA Approaches (aka management styles)

This week I’m wrapping up my notes on a very interesting blog from a chief architect with detailed experience guiding EA functions. The article in review this week is really quite fascinating because the author contends that he has observed various EA management styles as follows:

Big Architecture. This leads to a massive undertaking to populate all the current state often following a framework or pattern like Zachman and TOGAF. The pitfall to avoid is not working on relevant business needs and instead documenting the asset portfolio.

Transformational Architecture. This has a lot to do with major transformational objectives such as a merger or shared service center or data center consolidation. The author notes succinctly the pattern as:  “big change = big design = architecture.” The risk with these is that EA can get completely dedicated to such initiatives that they have no bandwidth for anything else. Projects like this are actually like major programs that will develop and launch numerous other programs and projects. They need dedicated staff that may include one or more EAs, but should avoid consuming an entire EA team for a period of time. In my organization, I see these kind of things happen again and again, and senior EA members are dragged into the role of realizing these transformation initiatives.

Project Architecture. The notion of this is that EA is a member of the project and controlled by the PM. The author of the article contends this is nonsense and I’d rather agree it is not the core focus of the enterprise architect. I like how the article goes on to explain that the EA role is architecting concerns “balancing competing demands between projects…..and between different areas of the enterprise.” Allocating EAs to projects has to be purposeful and typically is for a governance role.

Program Architecture. This is a cross between transformational architecture and project architecture. It tends to make sense, but the ideal way to realize this is to ensure that EA has project resources or an implementation partner it can direct or review.

Portfolio Architecture. Focuses architecture on a swath of projects in a given portfolio, and typically these are somehow interrelated as a network of projects. For example, Sales and Service projects.

Operational Architecture. This style is more IT service delivery focused and tends to be the most relevant place to start the EA practice.

Procurement Architecture. The EA style is focused on the purchasing that IT drives and is concerned with the financial optimization. This can unfortunately lead to EA getting bogged down in obscure purchases.

Policy Architecture. This EA mode is driven from a policy point of view and can focus entirely around the governance and upkeep of the policy. It’s depicted as a dry role and lacks creativity.

Model-based Architecture. This is similar to big architecture in that there is an intent to document models in hopes of using them.

Silo-based Architecture. This is what happens when dividing EA members into business, technical, data, solution, project, and application architects. It alsos silos to get created.

Opportunistic Architecture. This style deals with tight budgets and has to be more focused on the best wins than larger teams do.

Guerilla Architecture. This is an interesting technique that deals as much with confrontation of the stakeholders who devalue or sidestep architecture. It’s difficult to be successful this way.

Overall, a good article and I can relate to nearly all of the different styles. I would say that reading this post was one of the more useful and important documents I’ve had the chance to review.


Post 17: EA Delivery and Valuation

In the EA chief architecture blog I’ve been reading and reflecting on this past week, an article focused on a team the author had taken over for and what ensued. Essentially, the EA team had a lot of “architecture material” written but this had not led to any delivery or plan for delivery. The intention was therefore to shape the next steps such that IT services acted on the concepts proposed and that build and delivery teams would implement and run it.

The key message in the article could be broken down by these 4 EA success criterias:

  1. Get [a team] with the right people
  2. Understand your customer
  3. Get a process [e.g. TOGAF ADM]
  4. Get some architectural artifacts to support the process [e.g. templates and diagnostic deliverables that lead to business outcomes]

The right people are experienced, can operate with a level of autonomy, and have deep technical and business knowledge. They’re pragmatic and have excellent communication skills.

A process will help focus on the pain points and largest business needs/risks. It sets up to understand the motivation and ensure the engagement and project are aligned to business goals. A process ensures guidance towards an architecture target. The author also contends that EA keeps tabs (this is the governance role) on delivery in a non-obstructive way. This time around I agree, though I still contend that not all EA work efforts must lead to delivery. And I disagree that an EA should be a “free” project resource as proposed by the author. We have to set some practical limitations on where EA ends and other, related solution, engineering and developer roles take over.

Finally, get some digestible artifacts that are useful and intelligible to customers. A 3” document or 60 slide, slide-u-ment is not going to cut it. The key message is “find the relevant facts for each customer at each stage,” which I find as large good advice.


Post 16:  The Mission of Enterprise Architecture

I received an interesting assignment from my boss recently to prepare a brief proposing that EA governance in our organization be adjusted so that all regional practices report operationally to our Corporate EA body, thus setting up a more central EA function. Today, our global interaction is mainly organized through a global workgroup, but this body doesn’t have the same management control over the resources or their approaches.

While looking for some inspiration on the topic I found an older blog from around 2006 by the title of Chief Architect. I found the content in this blog to be a bit off-the-cuff and lacking detail, but I could appreciate the directness of his style and many of the ideas. I read three articles in particular that caught my attention and I’ll be focusing on these for my own blog posts this week.

The first article I’d like to highlight concerns the mission or purpose of EA. The author contends simply the core axiom, that IT is there to serve the business and goes on to argue about the failure of some IT organizations’ failure to recognize the importance in linking IT strategy to corporate and business strategy. The proposition is that Enterprise Architecture is the function of IT that shows how such organizational strategies will be realized and the most appropriate use of information and technology to deliver on those goals. That said, the article contends that architecture outcomes that do not somehow connect with implementation are less than irrelevant. To underpin this point, the author points to the myriad of modeling diagrams that many (most?) EA practices produce at some stage in their process and indeed whole notations have been established to support. The notion is that “delivery is all.”

I agree with most of the author’s message but have a problem with two aspects. First, in disagree with the premise that EA be so directly subservient to IT. This sets EA to take an IT focus. Based on my limited exposure, I think EA works best in IT, but it has to be sufficiently close the the CIO to function. However, a problem can result if EA is limited in its scope of what is considered the “enterprise” which can happen when stuck in IT and losing sight of production operations such as plant technology or even business processes. An alternative might be EA existing as part of the strategy function itself, closer to the CEO or midway between the CTO and CIO.

Second, I don’t think EA has to result in implementation to be relevant. Of course, proposing a transition architecture or roadmap to the target state is a key objective of EA, but this will rarely result in an implementation itself. EA’s role is 90% in the planning phase of a project lifecycle. But this is only about 10 or 15% of the project itself. The other 85-90% is implementation where EA’s concern shifts to one of governance for the target architecture. If the project fails or never gets off the ground, was EA’s job irrelevant? Hardly! There’s a lot EA can’t control, but it’s job might just set up the strategic limitations of a given initiative. If the business case turns out to not be there, EA may be viewed as successful in guiding as much toward non-implementation rather than throwing good money after bad money and pushing ahead.

The author’s summary is as follows:

  • Enterprise architecture derives from the business’s objectives for IT
  • Enterprise architecture starts with business processes
  • Enterprise architecture provides the direction for the use of information, communications, applications and infrastructure
  • Enterprise architecture management must find ways to ensure delivery

I find fault only with the 4th bullet and even then I think some context would help to make the case.


Post 15: Cloud and SaaS Risk Dimensions

Our organization has invested in SaaS solutions in recent years and there is a strong indication the trend will continue. There continues to be growing interest in maturing how we approach security with regard to cloud usage. EAs need to have an awareness of how security affects technology selection. I acquired an article from Gartner through my graduate program that is a bit dated, 2013, but still provides some good insights to structure our thinking. EAs and security professionals need to have such insights to assess the risk aspects of different forms of vendor provisioned IT services.

What I realized from this whitepaper is that our risk increases by the mere fact that it becomes increasingly harder to assess and control risk with our data further and further distributed and shared with partners in the cloud. In order to help define where to begin to assess our risk we need a model to understand where the boundaries of control exist and where risk is greatest. Figure 1 is an excerpt from the Gartner research which can I find a simple yet easy model to help assess where to focus our magnifying lens.

874 post 15 figure 1
Figure 1. Excerpt from Gartner article concerning the distribution of security responsibility.


Gartner resource #G00247629:  Analyze the Risk Dimensions of Cloud and SaaS Computing