Business Architecture

On the road to a Business Architecture Manifesto

by

One very powerful metaphor that has reverberated throughout the technical community, in the past few years, was the Agile Manifesto.  Created by a group of folks who wanted to communicate the principles that drove their thinking, the Agile Manifesto has been a very useful tool for deciding if a particular practice is being done well.  I think it may be time to build one for the Business Architecture space.

That said, I am by myself, sitting in my living room.  I am in no position to speak for the community of business architects.  So, this submission is a suggestion for content that could be useful when the conversation begins.  It is my personal opinion about the principles of business architecture.  I would hope to bring this material to a group of other BA practitioners, as my contribution, to develop a full consensus on business architecture manifesto.  

First off, in order to develop principles for business architecture, we need to describe the problem that we are trying to solve. 

The problem that business architecture solves

Business architecture is a relatively new field that addresses an old problem.  Most business people recognize the underlying truth: the structure and practices of your organization directly impacts your ability to deliver the intended value.  Whether we are talking about a military service, a civilian government agency, a non-profit organization, or a for-profit business, the structures and processes that a leader chooses to employ will impact the results that the organization will produce.  That includes both intended and unintended results.  So the basic problem is this: how do we deliver on our mission while maintaining our values?

Business architecture gets to deal with a slice of that problem.  As people, we need to organize around a common shared mission.  We need to know what we want, and we need to go get it.  Humans can be pretty haphazard.  Business architecture does not address every issue.  Business architecture attempts to answer this question: what is the optimal way to organize?  Business architecture typically does NOT answer questions around the integration of corporate controls, or supporting activities like how to find staff to fill new roles.  Business architecture is focused on the narrow slice of “how to organize.” 

So why do we need business architecture to solve this problem?  There are literally hundreds of good, well researched, books that offer useful insight for solving this problem.  Why use a business architecture approach?  Because BA brings a novel approach, one based on the rigorous application of conceptual traceability, process improvement, information science, and mathematics.  While most of the business analysis methods prior to business architecture were founded, fundamentally, in social science, mechanical engineering, and even education, business architecture focuses on the newer sciences that have emerged in the computerized age. 

How does business architecture solve the problem

Business architecture’s unique value proposition is to focus on answering the questions of business structural and organizational effectiveness in a way that is rigorous, quick, clear, consumable, and value-focused. 

We are uncovering better ways of developing business insight by doing it and helping others do it.  Through this work, we have come to value:

Consistently reusable methods over Piecemeal assortment of best practices

Rapid insight over Deeply accurate models

Clear choices over Nuanced decision trees

Consumable deliverables over Consistency with external frameworks

Value-driven prioritization over Justification of the status quo

 

That is, while there is value in the items on the right, we value the items on the left more.

 

To break that down:

  • Repeatability, Reuse, and Rigor.  There are many ways to understand a business.  Business architects will expect you to pick one of those ways (one conceptual model) and then stick to it.  The rigor comes from sticking to the model.  If your enterprise is focused on creating a smooth customer experience, then the business architect will leverage the customer experience work done elsewhere, and will drive a business stakeholder to follow along rather than make something up.  While products must be creatively and freely developed, the organization itself must be architected and engineered.  Rigor matters.
     
  • Rapid Insight. There are many ways to analyze a business.  Business architects will work to reduce the overhead of their analysis methods so that they can produce valuable answers in a very timely manner.  Business people are not rewarded for taking a long time to do an excellent job.  Most will be better rewarded if they do a reasonably good job in a shorter timeframe.  While accuracy is great, the value of information is inversely proportional to the time needed to produce it.  Speed matters.
     
  • Clear Choices. If a business person cannot tell what the recommendation is, they won’t follow it.  If the business architect cannot produce insight that is clear for the business stakeholder, the architect will not effect change.  It is not good enough for a business architect to be quick and correct… they must also be clear. 
    The amount of information, and the coarseness of the decisions, depends on the level of the stakeholder.  At any level, a decision maker should be provided a short list of options (often 2 or 3) where the distinctions between them are clear.  This rule applies at all levels of the organization.  One strategy from a senior manager may require a choice among three different tactics for a department head to choose from.  No one person needs to be concerned with the entire decision tree, except perhaps the business architect himself.   The ability to make decisions is proportional to the clarity of the choices.  Business architecture favors clarity over nuance.
     
  • Consumable Deliverables.  In order for business architects to be successful, they must deliver a plan for the execution of business strategy.  That plan has to be something that the impacted stakeholders can understand and use.  In other words, the output of business architecture must be consumable.  Reams of technical detail are rarely useful.  At the other end of the spectrum, vague goals and promises of value may be just as inappropriate.  Recommendations must be provided using words and metaphors that the actual impacted business stakeholders understand.  They must be provided using forms and templates that the existing organization will recognize and can quickly use.  While consistency with frameworks and practices are important, business architects value consumability more.
     
  • Priority based on Business Value.  Business architects can spend their time on many tasks.  In addition, they can recommend that the organization spend time on many tasks.  Sometimes, even an efficient use of business architecture would be a waste of time if the resulting advice is unlikely to deliver strategic insight.  The selection of tasks, which to do now and which to do later, is of critical importance to a business architect.  While all supporting tasks can be justified, business architects will give priority to tasks that directly lead to actionable, consumable, value-driven business advice.

 

I’m always looking for insight and feedback from the community, so please feel free to add your comments. 

Please note: if your comment is long, the software will sometimes have trouble.  Write it in notepad or Word first, and then cut and paste into the comment edit window.  Don’t be afraid to send it more than once.  I will delete duplicates.  If all else fails, e-mail your comment to me and I’ll put it in.

There’s no short-cut to experience

by

At least he was open about it, I guess. “Tell you what I’ll do”, he says to my colleague here in Guatemala, “I’ll find you a client, then I’ll sit in, learn everything you do, and then I’ll apply it in my own business. How does that sound to you?” Uh, no. Not a good […]

Enterprise Transformation and Open Group

by

Enterprise-architecture is dead – long live enterprise-transformation! Or so it would seem, from the description of the current Open Group conference at Cannes. Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – […]

Connection is what matters

by

A great Tweet from Oscar Berg this morning: oscarberg: IMO #socbiz is primarily a mindset&way2see business in increasingly connected & digital age I think he’s exactly right there: in essence, ‘social business’ is a different mindset about the way a business relates with others, and also with itself (as in the now seemingly-all-but-forgotten ‘Enterprise 2.0′). […]

Analysis, Synthesis, and Scope: Business Architecture vs. Business Analysis, part two

by

A few days ago, I quickly dashed off a post on the difference between a business architect and a business analyst.  The reaction was immediate and rather vociferous.  The IIBA took me to task for saying that a business architect is NOT a business analyst.  In addition, Tom Graves (Enterprise Architect) asked me to consider the possibility that the two roles are primarily different in another way, altogether.  Tom asked me to consider the possibility that an architect role is primarily one of synthesis (putting things together), while an analyst role is one of analysis (taking things apart).  I beg to differ.  This post included my thoughts on that distinction.

Graves’ trilogy: Analyst-Anarchist-Architect

Tom has pointed out, in past articles, that there is real value for enterprise architects to consider the Hegelian triad of Thesis-Antithesis-Synthesis.  In his post, Tom presents a triad, based on Hegelian thinking, three different roles in sequence: business analyst – business anarchist – enterprise architect.

In Tom’s thinking, the analyst is good at creating an initial hypothesis that represents incremental improvement… at doing things right.  The anarchist is the role that questions the assumptions underlying the analysis.  It is the role of anarchist to test those assumptions, and make sure that they do indeed align with the real world of “trial, error and experience”.  The anarchist prevents us from accepting our assumptions.  The architect puts it all back together.  According to Tom Graves:

And the architect role is about bringing it all together again. It’s the ‘synthesis’ part of the triad; but it’s also about the Concrete, about making things real, being effective – about doing the right things right in a concrete, practical way.

Here is where I have to take my hat off to Tom.  There is a very important thought process going on here, and one that I both agree with and can immediately use.  I admit to not having taken the time to really grok Tom’s post prior to now, but I couldn’t agree more with the thinking process.  You have to form an initial idea, then break apart the assumptions in order to test the initial idea, and lastly bring it all together in a solution that actually works.  It’s an excellent approach.

Shouldn’t this kind of thinking simply be a template for each individual person?  Shouldn’t one person perform all three activities?  Tom addresses this as well.

One way to resolve the architecture of that architecture is to have just one person doing all of those roles – after all, they’re different roles, not necessarily different people. But that can sometimes be quite a ‘big ask’, because each of the roles does demand different skillsets, different paradigms, even different worldviews – again, somewhat tricky.

Tom suggests that it is difficult for one person to perform all three, and that large organizations (and large markets) may have the freedom to separate out the roles into different people.  It’s an interesting idea, but I don’t know if provides the clarity I’m looking for.

I believe that Tom is completely right in one respect.  Solving a problem effectively requires that you go through stages of thinking.  If you simply look at the problem and conceive of a couple possible solutions, you could just as easily fail to consider the optimum one (not on the list), or choose the wrong solution (whatever “wrong” means).  In order to reach the best possible decision, you must go through the additional steps of antithesis and synthesis. However, I don’t think that this distinction is sufficient to explain and position the roles of Business Analyst and Business Architect. 

The process of thinking through a problem applies to ALL roles that solve problems (a fairly long list).  It doesn’t just apply to business analysis.  Following the path from thesis to antithesis to synthesis is an art practiced by artisans, craftsmen, mathematicians, scientists, engineers, leaders, managers, and politicians.  It is best practice for all of human thought, and not just one area of human endeavor.  Everyone who thinks, and considers, and solves, should use all three steps.  To use Tom’s terminology, each person should be an analyst, an anarchist, and an architect.

Different Efforts, Different Results

Tom’s thought process is excellent, but I don’t believe it answers the core question.  Over the past few years, we’ve seen the emergence of two different “job titles.”  Both jobs emerged out of the need for the information technology division to address business problems in new and novel ways.  The core question that I’d like to address is simple: is this something that one person does, or something that two people do?  Are we more effective, and efficient, to separate the roles and responsibilities?

Some things we all agree on.  The business analyst role is much more tactical than the business architecture role.  Traditionally, the business analyst is required to understand the problems of a business area and to document the requirements of the business in solving them.  The business analyst is NOT accountable for developing the solution, or even the vision for the solution (The solution architect does that).  He or she is accountable for understanding the problem and documenting the requirements that the solution must meet.

The business architect role is a more recent innovation.  This role emerged out of the need to insure that departments and divisions are using IT resources correctly by asking for the right problems to be solved.  From there, the role has expanded to a non-IT-focused value proposition.  The business architecture role is important.  Without the business architect involved, we may do an excellent job of solving problems that the overall enterprise does not need solved, when the real enterprise-level problems are going unaddressed or under-resourced due to the long list of demands from the existing businesses.

The business architect is different from the business analyst because he or she is fundamentally charged with four different responsibilities:

  1. understanding the actual enterprise-level needs and the relationship between one business area in respect to the overall strategies,
  2. partitioning the services that one business area should produce and the needed level of maturity for those services,
  3. creating a vision of those services, from the perspective of the business, and
  4. insuring that it aligns to the actual and proposed architecture of the business as a whole. 

Note that (2) occurs rarely… only when major changes to the business models themselves occur. 

Some analysis will perform responsibilities (1) and skip to (3).  In most cases, that works.  On the other hand, performing responsibilities (2) and (4) requires the skills of an architect.  There are two different skill sets here.  Can one person do both?  Yes.  Should they?  That depends.

As these roles continue to mature, we need to either carve out distinctions, or merge them into a single role. 

Business Analyst and Business Architect as one person

In my prior post, I made the case that there are many differences between a business analyst and a business architect.  My prior post was based on the assumption that there needs to be two different people playing these roles.  That assumption is NOT valid in all cases. 

There are many situations where it makes a great deal of sense for the activities of business architecture and business analysis to be performed by ONE individual for financial and logistical reasons.  For example, if the IT unit in question has a small set of responsibilities, or if we are talking about a medium-to-small business (or business area), there just isn’t enough work to keep two different people employed full time in complementary roles.  Within my company (Microsoft), there are some smaller areas of the business that are covered by one individual who performs both business architecture and business analysis tasks.

The question that I have, however, is simple.  While it is possible for one person to perform two jobs, does that mean there SHOULD be one job?  Should we merge the roles so that every business analyst should be an architect, and every business architect should be an analyst?

Business Analyst and Business Architect as complementary roles

Regardless of what we want to happen, reality is going to keep getting in the way.  Both roles exist.  Sometimes they intersect.  The real challenge comes when two people have to play complementary roles, one as a business architect, and the other as a business analyst.  In larger organizations where business architects are appearing as independent roles, and in situations where consultants are being hired, this situation is increasingly common. 

In order to be effective, these two folks need to have clear accountabilities.  They need to be clearly supporting the success of one another, but able to succeed independently of one another (the failure of one cannot prevent the success of the other).  In order to meet these criteria, there is one very important distinction.  Both must have a different set of problems to solve, and both must have the full scope to solve those problems.  Both must perform the three steps of emergent thought that Tom points out: thesis, antithesis, and synthesis… or analyst, anarchist, and architect. 

There is no good source, in existence, for clarifying those accountabilities.  The Business Analysis BOK focuses on skills and methods, not accountabilities.  The Business Architecture BOK focuses on different skills and methods, but not accountabilities.  Both fields seem happy to simply overlap.  That is probably OK from the perspective of describing the fields.

However, in an actual organization, where people have jobs to do, more clarity is required.

Conclusion

No matter how we reconcile these two roles, we need to understand that the growth of business architecture will not be abated just because the profession of business analyst has laid a moral claim to the activities that business architects have decided to focus on.  Rather than argue about whether business architects are, first and foremost, analysts, lets look at whether we can address two key questions:

a) Is it better or worse for these roles to be independent?

b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?

Arguments don’t matter.  Answering these questions… that matters.

Design Thinking

by

I have just finished reading Roger Martin’s book “The Design of Business”. He is describing and promoting the use of “design thinking” in developing products and services. Basically he is writing about the balance of creative design and analytical design, which is a key principle behind successful business architecture. The purpose and challenge of the business architect is

The post Design Thinking appeared first on Louise A Harris on Enterprise Business Architecture.

The difference between business architect and business analyst

by

[Author’s note: within an hour of posting the following article, Kevin Brennen of the IIBA dry-roasted the post on his own blog.  You can find a link to his entry here: Business Architecture is Business Analysis.  I have made an attempt…

An architecture of enterprise-culture

by

[A collection of notes that I made somewhen around May 2010 that I don’t seem to have published before, and seem to be relevant now as I explore my own business-model. (Not an April-Fool joke, by the way. ) ] A culture [enterprise-culture] is a set of prioritised values and goals – usually ill-expressed, conflicting, a muddled-mixtures […]

Architecture Capabilities through Business Models

by

For some time I have been working with adapting the business model canvas for explaining how an enterprise architecture program delivers value to the it-department. The scope of the model has been on the foundation architecture where the outcome of the enterprise architecture program is mainly used by the IT department. I am aware of […]