Friday, June 26, 2009

Where Does Business Architecture Belong?

It seems that there is quite a bit of discussion about where business architecture belongs. Should it be placed in the business or in technology (EA). During these debates I have heard comments such as "whoever controls business architecture controls the strategy" - I wonder which strategy - or that the placement is important because we need standards or structure or a framework. What does that have to do with placement? What I haven't heard much of is how to best facilitate the needs of the business. To me, that determines everything.

This is an organizational design issue and any model can work. What you need is focused, dedicated, conciencious, capable, aligned individuals perfroming that role. Where you stick them is not nearly as important and depends more on how you choose to define and scope the role/discipline. An even more important factor in this decision is the culture, context, structure and dynamics of your current organization.

Will the business usurp the BAs whenever the need arises by diverting them to tactical, operationally focused tasks? Then get them out of the business - unless business architecture is a "get to it when you can" kind of discipline. What? Is that even OK? Well maybe not,but if your organization isn't involved in significant programs of change - or if its only plans to change are over a long horizon, then this may be OK. I know this suggests that the organization may not be prepared to adapt, and that the reality in today's world is a constantly changing landscape, but if that is the strategic intent of the organization you need to either sell the need to spend more time up front, find a way to demonstrate value early and often, or find a new job.

What if EA is a hard core standards driven dictatorial governance machine? If EAs idea of BA is to build frameworks and drive business to comply so that it is easier to build and manage an enterprise infrastructure, then the entire EA team should either be let go, OR you should get BA out from under their influence - ulness your idea of BA is building technical frameworks. Don't however expect the business care about these things unless they help the organization thrive. Whatever does not shoud be jettisoned.

So, will a framework help the organization thrive? Perhaps, but only if its structure allows for organizational flexibility, agility and adaptability. Only if it can help solve real world problems in a dynamically ambiguous, complex and unpredictable environment. If, however, you take years to develop your framework before it can be utilized, you are going to face strong resistance, and rightly so. Find a way to build it out iteratively and incrementally, adding value where it is needed most. The quickest way to win the hearts of the business is to help solve problems.

If however you help solve problems in ways that compromize the future (again, organizational flexibility, agility and adaptability) then you are part of the problem. Remember Senge said that today's problems were yesterday's solutions. But, you may argue, that is precisely why BA cannot be trusted to the business, because they unknowingly compromise the future while trying to solve the problems at hand. I agree, but technologists are equally culpable. This is one of my principal gripes against some agile methods, which I won't mention here (SCRUM). Being agile and adaptive by fulfilling the evolving/changing needs of the business with a blind eye to the future is irresponsible.

I guess this begs a question around whether it is better to constantly throw work away (because the future is constantly unfolding) or whether one can actually build an infrastucture that can adapt and evolve. The answer here is very complex I'm afraid. Remember that technology is a beast unto itself, ever evolving - take cloud computing as an example, all the rage right now. And while new technologies are fun and potentially useful, an organization can only absorb so much change before it goes daffy - and technology is only one thing that is changing in large and complex organizations. I would argue here that if you slow the pace of technology adoption you can accomplish more. This sounds silly, but its true.

I see I am off the point, but I like where I've rambled. The point is not so much who owns BA, but how the organization is collaborating to design the future. Remember that there are many other players: Subject Matter Experts, Process Consultants, Process Analysts, Enterprise, Data and Solution Architects, Program Managers, Technologists, Business Managers, Line Workers. ALL of these roles (and more) contribute to building a successful and sustainable future.
Collaboration is the key, that and a razor focus continuous improvement. Stop arguing, roll up your sleeves and open your eyes and ears. Now, how can you best build an organization that effectively learns, adapts and grows, an organization that thrives? That's the real question.



Join us at

Monday, June 8, 2009

Socially Responsible Business Architecture

I'd like to coin a term "Socially Responsible Business Architecture" or SRBA (SoRBA?). I think this is an important topic from the perspective of sustainability.

This type of business architecture is about recognizing interdependence and social responsibility by maximizing the value for ALL stakeholder. This includes everyone - from employees to their families to partners to investors to suppliers to service providers to customers to communities, you get the point.

To do this in an organization would require merging the organization's value driven systems with the business driven architectures. This would align an organization's social values with its architectures and potentially achieve higher level of sustainability.

We all should leave the world a better place and create as little negative byproduct (waste) as possible, and as architects we have the unique ability to design our way to SRBA.

Join us to discuss this topic in more detail at


Cloud Oriented Business Architecture

You can't help but run into a cloud lately. I just finished reading Peter Fingar's article for BPTrends on Extreme Competition where he outlines Cloud Oriented Business Architecture (COBA). My initial reaction is that, for large corporations, this is not much different than the idea of extended enterprise. While it does include the social networking aspect which is huge, the article did not put forward much more than a Service Oriented - Business as Service model where an organization hones its core competencies and relies on partners (whether negotiated at the time or contractual) to fulfill the rest of the value delivery cycle. He does mention an idea called Value Threads as opposed to Porter's value chains, but this seems a bit ethereal as enterprises are currently using rules platforms to customize process for different types/segments of customers.

I can see, from a holon/rhizome perspective (ask if you're interested) where this can bring up some interesting discussions. Still....I think its a repackaging (or continuous improvement) of some very well known ideas and concepts.

I've started a discussion on this topic on our social site: hope you join us


Toward a Universal Business Model

In my quest to define Business Architecture as an Integral Discipline, I have constructed a "universal" operating model. It is my interpretation and extension of Dr. Osterwalder's excellent work in his Ph.D. thesis. I have said before that that businesses - and architects - focus too exclusively on the "throughput" processes. And this model is really no different, but having said that, it does provide a sound framework for the "value delivery" aspects of an organization. Here are the related throughput elements. The model is larger, but I wish to focus on this section. Please contact me if you would like to discuss the entire model.


In order to quickly grasp the essential elements, I have organized them into a value wheel:

Value Wheel
Value Proposition
Target Customer
Distribution Channel
Value Configuration
Cost Structure
Revenue Model

These elements are the targets of organizational change and each element belongs to one of three primary concerns: Achieve-ability, Affordability and Sustainability. The Value Wheel above is color coded to allow us to quickly assess which elements have the largest contribution to these three concerns.

Yellow = Achieve-ability
Red = Affordability
Green = Sustainability

Achieve-ability is primarily determined by how value is configured. The quality of inherent capabilities and partnerships have a profound impact on achieve-ability. Affordability is primarily centered around cost structures and the revenue models and sustainability is about maintaining and cultivating valuable relationships with your customers through various channels of distribution.

If you cannot align these value wheel elements in demonstration of a program's primary concerns, you should not move forward with the change.

With respect to completeness, the model, as I said does a fine job of looking at the throughput or operational aspects of an organization. To be complete, however, we must layer Performance and Learning. Performance takes place in an environment - it must be measured in context - and learning occurs through observation and insight. Borrowing from the work of Donella Meadows and Jamshid Gharajedaghi, I can extend the throughput model as follows.

Extended Model

In the above model, the original throughput elements are represented by the element box at the top. I have extended performance as an aspect of Organizational Fitness which is determined by effectiveness and efficiency. I have also added the learning component which is the primary input to Strategy Planning. The hexagonal shapes represent a variation on Gharajedaghi's high level organizational systems - only one of which is throughput.

The Structure or body of the organization is composed of these systems and all of the systems support needs of the organization. The Structure of the organization enables or constrains organizational fitness. Strategy shapes the organizational structure (and visa versa). The ways in which the structure of an organization is changed - short is through the use of leverage points (see Meadows). The call-out that connects to the Structure Element is a list of those levers. The list begins with the simplest of the levers, parameters and moves toward ever more effective levers.

It is essential that a Business Architect (BA) understand the major elements of a business model, and their relationships to each other. It is also essential that the BA understands how these elements are related to the larger structures of the organization and how each might be manipulated to increase the overall fitness of an organization.

The models demonstrated here are fully represented in my Framework for Organizational Fitness.

Please join our online community at

© 2009 Inside Business Architecture

Wednesday, June 3, 2009

Review of the BA Role in TOGAF v9

I just reviewed TOGAF v9. Here are my thoughts. This framework does a fairly good job introducing the role of the business architect. The structure of the document suggests a waterfall approach to the business architecture phase as well as the others. I know that it speaks about iterative development, but can easily be interpreted otherwise and it is essential to be iterative and adaptive - your architecture WILL change and it must be adaptable (now and in the future).

I do agree completely that Business Architecture is a prerequisite for other architecture work (again I would say leading slightly here because it is essential to have the other domains involved as early as possible). The role of the BA is essential as a bridge to structure the needs of the business for buy-in, illumination and analysis and for consumption by technology.

A good point, often overlooked, is the BAs role in value demonstration. My experience is that a good BA can make a business case and demonstrate the need for change better than almost anyone.

Organizations, and programs, don't always have their mission, vision, goals, etc. well defined and aligned. This often falls to the BA and is the reason that I advocate the BA having a sound understanding of business strategy and enterprise planning.

I take a small exception to the statement that business strategy defines what and the BA defines how. To me the BA defines the what more clearly. But I nit pick.

TOGAF mentions the common experience of having to do legwork to scope the program effort and get buy-in and determine feasibility. I find this to be an absolutely essential aspect of the job. Also, managing value delivery is vital and this is done by keeping a close eye on the prize and making smart trade-offs where and when necessary - this should occur continuously throughout a program life cycle. I know that some will think that this is the job of the Program/Project Manager, but the BA is the one who demonstrates the way forward and therefore should have a razor view of the way forward. It is the role of the BA to help decide whether changes to the program are justifiable.

Reality often dictates that a BA has to work from the middle out, working top down on the vision (and buy in) and working bottom up on what do we have and how does it need to change. These two approaches (working simultaneously) help ground the program in reality.

TOGAF speaks of repositories. Anyone maintaining anything that is versioned should have a repository. This does beg interesting questions concerning configurations. If we try to build our models and descriptions in tools that can be extended toward development (MDA) then configurations become important artifacts in the delivery of business change.

Service orientation is another must for the BA. NOT fine grained services that expose technical interfaces, but the bundling of activities (and processes) into interfaces and components into business services. This is less granular and should immediately speak to the business - if it does not then you're probably doing it wrong. Service orientation can also be applied to platforms and business units in a componentization of the organization.

TOGAF feels document heavy, so I would advise a little caution. I have seen organizations adopt RUP as very document centric and it is easy to lose focus on the task at hand which is improving the fitness of the organization. So my advice is to not interpret this framework literally. Use the documents as suggestions and seek out tools that allow you to build value as you document - tools that are building your product AS you document. IBM's Rational Tools do this well as well as their Business Modeler and System Architect. There are quite a few of these on the market.

I would not take the inputs and outputs as essential. Very often these are simply not available. I would not create new kinds of documents unless absolutely necessary.

One more point on iterations. Change management is very collaborative and iterative. I recommend a Program Office that has business representation, a BA (and perhaps the other EA roles), Program Manager, and the project lead(s). This is the minimum. Other possible roles are Communication Management, Change Management, etc.

All in all the TOGAF v9 is a good introduction to the role of a Business Architect.

Join the community for business architects at Inside Business Architecture.