Thank you for your Visit

As a professional working in business transformation and organizational change, I have had a number of roles: business analyst, project manager, security manager and architect. As an Enterprise Architect, I take responsibility in helping all involved in understanding their role in realizing the desired business outcome.  As an active instructor and consulting Architect, I look forward to your feedback and hearing about your organizational challenges.  In working with the Open Group, I also look forward to build a strong community of capability-based thinkers and help make transformation straight-forward.

About Me – Tamim Rahman

Two Things you Need to Know About Enterprise Architecture

1. Are you looking at Enterprise Architecture as a Function or Strategy?

2. What is the difference and why does it matter?

Many medium to large organizations have “architects” and a large majority of them are found in departments that provide the organization’s information and communication technology (IT and ICT). These organizations have a department/group called Enterprise Architecture (EA) that is supposed to help the organization bring about complex changes in IT and in more cases, to those that are consuming IT.

The function of being able to plan and deliver change to an ever-changing ecosystem is essential for any organization. Some organizations have done well to establish the function of the EA group, it is visible throughout the IT organization and involved throughout the change lifecycle. The function is known, people are assigned roles, the work products produced are defined and processes to deliver the defined changes are well understood. Few organizations have achieved this level of functional maturity, but even for those that have, this is often not enough.

EA should also be seen as a strategy, a mindset that can provide insights into important business decisions; in this respect EA is a management tool set. In this context, EA is abstract; it is a philosophy that can provide needed insights to support the goals, objectives and “gut feel” for senior leaders.

In brief – certainly not exhaustive – there are some important notes to remember when looking at EA as a strategy.

1.     As a strategy, EA is not performed only by Enterprise Architects. Many roles and people across the organization can provide valuable perspectives and insights. Through its tool sets and ability to have both a broad and detailed view, EA can unite these perspectives and identify commonality in the natural conflict of an organization.

2.     EA does not have ownership, (management is accountable) and therefore does not make business decisions. EA can inform decision makers of what they need to consider. Questions asked require more than “yes” and “no” answers and EA can provide insight into what will make the desired outcome successful and thereby reduce risk and increase viability of success. Whatever the decision, EA must find ways to make the desired outcome successful.

3.     EA does not define an organization’s purpose. EA must understand the organization’s identity, mission and culture and provide its findings with these considerations and is therefore tailored for an organization.

Keep in mind that not all organizations will call this work “Enterprise Architecture” (some call it Business Alignment) there are organizations that are asking the right questions and applying EA as a strategy successfully and make timely and good business decisions. The label of “EA” is not important but the application and acceptance of it is.

Why does this matter?

It is important to know the challenges faced by an organization, is it with decision making, alignment and communication to its parts or with execution. Those that have had careers in IT and have worked their way to an architect position have a good depth of IT knowledge and can help in the delivery of EA as a function for IT. The common obstacles that they face is being able to convince IT management of their approach and the roles that they should play in the delivery of IT solutions; this requires a good understanding of EA as a strategy which requires leadership support to be successful.

Those that are looking to create, improve or adopt Enterprise Architecture should remember:

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” – Sun Tzu

You can make incremental changes to an existing EA function to make marginal improvements, this requires a good understanding of the function of EA. To reap the big rewards of being efficient, effective and having strong organizational alignment, EA as a strategy is essential. The key to its successful adoption is knowing what to communicate to management and decision makers.

I look forward to your comments and feedback, let’s have a conversation.

Featured on LinkedIn

Draft Day: What We Can Learn About Strategic Planning and Architecture

New Picture

In the movie Draft Day, Kevin Costner plays the role of Sonny Weaver, the GM of the Cleveland Browns.  After his father and legendary coach of the team passes away, the Browns are in a rebuild and desperate to put together a team that its fans can support and win on the field.  Early on, the team owner threatens to fire Sonny unless he is able to make a big splash in the upcoming draft of new players.  His coaching staff and new head coach have their own requirements for a defensive tackle and running back; two key players desired by the team are expected to be drafted in the first round.  Sonny also has his own agenda, he wants to see a team that he has put together win. It is also clear to Sonny that if he does not make a big trade and take the first overall pick and draft the highly decorated quarterback, Bo, he will be fired.

We see this dilemma unfold constantly in our work and personal lives.  We have some stakeholders that have a certain need and also have a solution of how to achieve it but the expected solution will not meet the needs of others.  At times we are a stakeholder, and at other times we may be the owner of the decision… what are we supposed to do?

As the movie continues, we learn more about the stories, motives and backgrounds of those involved.  Sonny knows that GMs of other teams would not hesitate to offload their garbage on an unsuspecting team and he makes several executive decisions along the way.  This movie does a great job of showing that Sonny is unwilling to sacrifice any requirement and demonstrates exceptional strategic and architecture skills.  Instead of eliminating the non-conforming requirement, he keeps them all at top of mind and pleads with all involved to let him do his job and to follow through with their actions after the draft is completed.  He uses his opposable mind[1] to transcend the conflict to create a win-win situation for all involved:

  1. Create a winning team without sacrificing the future of the franchise
  2. Satisfy the owner in making a big splash
  3. Satisfy his coaching team
  4. Realize the team he has built
  5. Reward those players with heart and true desire to win

Lessons We Can Learn

When dealing with any transformation, any single individual can prevent its success.  The status quo is not acceptable to anyone yet not everyone will agree on what needs to be done.  A committee approach would not work in this context; decisions need to be made quickly and agility is required to obtain and process new information.  If we waited for consensus or majority, the time to make the decision will have expired.

In general, decisions made by a team that is able to transcend conflict are more informed than any single decision maker, but when agility and quick action is required, do we have the trust and confidence to let someone else take the lead?

By answering “No”, we will not embrace change and realize a better outcome but a blanket “Yes” does not guarantee success either.  The person taking the reins needs to show that they can act unselfishly and for the best interest of all involved, they also need skin in the game and have something to lose if the desired outcome is not achieved.  Our trust is not a commodity that can be easily given but we should also not hold it back when we do not necessarily agree with the cause and effect in achieving our goals.


[1] See Roger Martin’s book, The Opposable Mind

Confusing Performance and Outcome Hinders the Application of Enterprise Architecture

High performance does not always get the intended outcome

Most postings on online forums such as LinkedIn focus on defining Enterprise Architecture (EA).  Even a broad consensus among those that practice it consume is at its best, a difficult proposition.  Those promoting their own points of view in an attempt to clarify EA inevitably result in creating further contention, confusion and prevent those that may benefit from such insights offered by EA; a true lose-lose outcome to the practitioner and consumer.

This phenomena is not unique to EA, we see this manifest itself in the natural politics of the organization.  What’s good for the greater Enterprise may be at odds with individual groups and leaders within the Enterprise and those with the ability or clout are able to steer more resources to their own objectives. An outcome is the result of the business decisions made by or organization’s management.  Senior management – the “Chiefs” of the organization – provides the organization’s priorities and insights to achieve the strategic intent but line of business management are responsible for executing the organizational investments that improve performance of the enterprise’s capabilities that results in the outcome.

Therefore, an outcome reflects the shared vision of management and performance is a measure of the organization’s outputs.  From personal experiences, a source of confusion stems from the outcome of the line of business versus the greater organization.  As an example, an organization wants to increase its online sales by 40% (outcome) and it will do so by increasing traffic to its website by 50%.  Its strategy is to launch new social media campaigns that are expected to fully account for the increased.  The lines of business involved include marketing, sales, IT operations and IT security.  The marketing team may over-achieve their performance and increase traffic by 100% but if IT security is unaware of this activity they may interpret the increased traffic as an attack and prevent the access of the organization’s message and sales.  IT operations may be unable to cope with the increase in traffic and transactions leaving many visitors disappointed as they are unable to complete their activities.  For sales that are made, the organization needs to have the inventory to meet this demand within the expected time of the customer.  Therefore, the performance of all of these groups needs to achieve a minimal level in order for the organization’s outcome – increase online sales by 40% – is realized.

As the example above illustrates, an organization needs to understand what outcome is achievable and what constraints need to be overcome.  It would not be rational for the organization to invest 50% of future online sales to achieve the desired outcome or to have such an expectation without a market/industry study to determine if the market would support this increase, how competitors would respond and so on.  The ability to realize the desired outcome is dependent on the organization’s understanding of both the industry and its own ecosystem.   An industry position that would be beneficial to the organization may have much greater obstacles to overcome than the benefits of the position; think about the challenges for a low-cost bare bones widget maker transforming into an innovative, leading-edge provider of widgets.  Likewise, what is easier for the organization to move towards may not be successful in the marketplace.

When creating an organizational position in industry, senior management will require the expertise of those who have strong knowledge of the industry and also insight into the constraints of the organization.  Correspondingly, intimate knowledge of an organizational function does not qualify the person to know what position the organization should take in the industry.  The application of Enterprise Architecture needs to be made to the context of the organization and the challenge it faces: do we have a consensus on the outcome and only then can we determine the performance that we need to achieve.

Avoid Poor Project Outcomes

I created this slideshare to articulate 5 of the most common pitfalls I have seen that sink even the best conceived of projects.

Is your organization aligned to tackle a major initiative?

We all want to do the right thing… but what exactly is “the right thing?”

The answer is certainly not absolute, it will differ by perspective and viewpoint.  What may appear to be “right” to our group, may not help the greater organization and vice versa.  In such case, what do we do?

We first need to understand what is preventing the alignment and understand the benefits to be realized if we are aligned.  I created this slideshare to illustrate the importance of alignment for an initiative that impacts multiple areas in the organization and why alignment is critical before we consider options to tackle our obstacles.

Architecture Requirements… Now Defined

What are architecture requirements?

I am pleased to announce that the Open Group has recently published a paper entitled: TOGAF®, an Open Group Standard, and Enterprise Architecture Requirements. This paper has been authored by QRS Architects Jason Uppal and yours truly.

Architecture requirements are fundamental in driving and creating architecture work products. While there may be commonality in understanding the concept of architecture requirements, their practical application, relationship to other requirements and driving of architecture work can be further elaborated.

Download Architecture Requirements Paper

Here is the abstract for this paper:

The understanding of requirements has been one of the most contentious issues between IT and Business. To resolve this conflict, many disciplines have emerged but progress to resolve this conflict has been minimal. Our view is that the root cause of this conflict has been two-fold:

1. A lack of common vocabulary, and
2. Clear accountability of the outcome

The Business often expresses requirements as characteristics of the solution rather than characteristics of the problem, and when they build a system based on the provided requirements, the system often fails to address the organization’s business opportunities. Re-definition and rework further increases time and cost to the project and to the dismay of everyone involved, the results get marked as one more failed IT project.

In this paper, we are separating the notion of requirements into two perspectives. For each perspective we have defined roles, responsibilities, and how requirements are elicited, analyzed, communicated, and tested. Most importantly, accountability for the completeness and accuracy is explicitly defined. To ensure clear communication, we have provided a set of architecture requirements for a major Business Transformation program.

We would like to thank the Open Group and their process of review and rigor in publishing this paper and we look forward to playing a role in evolving the next generation of the TOGAF® specification.

This paper also supports our advanced training programs to help architects and the business transformation community work together to realize desired business outcomes.

Avoid this TOGAF Implementation Pitfall

This has been one of my most well-received presentations on slideshare and LinkedIn.  From my experience as a trainer and consultant, organizations often confuse the ideal process flow with their existing work flows and in an attempt to be compliant, ditch their internal methodologies and replace them with the framework du jour based on a strategic directive and then find out that the framework is not complete to describe how the work needs to be done.  I have seen this happen with PCI DSS and also with TOGAF; we must understand that these specifications describe what needs to be considered, the actual work flows implement the described considerations and qualities.

Free Book Download: Business Transformation Made Straight-Forward

Along with Jason and Stewart, I am pleased to share this book that we published in December 2013.  This is a comprehensive book that discusses the role of architecture and capability-based thinking in helping an organization transform.  Transformation is very disruptive and there are more than a single approach to make it successful.  This book highlights considerations that need to be made from senior management to the operational staff of the organization.  In addition, tools and guidelines are provided to show how the work is done.

Download the book from the link on the last slide. No forms to complete, a straight-forward download.

A Key Element Missed by Many Training Programs

This is a slideshare presentation that I created to highlight the importance of establishing a clear understanding of the learning objectives and outcomes.  From the experience of hundreds of training programs, I have seen successes and a fair share of missed opportunities.  From the failed programs, a key them emerged: These programs lacked a clear understanding of the learning objectives and outcomes.