Thursday, July 9, 2009

End to End Process Optimization is Overrated

There, I've said it. With modern insight into organizational design, the idea of analyzing an entire arbitrarily end pointed process seems counterproductive.

Let me defend myself. Today's environments are extremely dynamic. The problem with dynamic environments is that the path forward is ambiguous, uncertain and often complex. To lay in highly optimized end-to-end processes is actually detrimental to efficiency.

Why is this? Dynamic landscapes are constantly changing making optimums hard to find and are brutally punishing even if you are near optimum - think steeply sloped. High structure (and tight coupling) does not allow the degree of innovation and improvisation required to navigate this type of terrain - it is sub-optimal for highly dynamic environments. What works are loosely coupled, coordinated and independent clusters.

This allows for co-evolution which is more effective than trying to evolve the whole process at once. It allows for localized innovation, improvisation and the exploitation of emergent strategy while the organization pursues a more deliberate strategy.

To accomplish this requires is a guiding melody of sorts - a simple set of principle which guide the clusters. This provides room for innovation and for the execution of emergent strategies that are still in harmony with the overarching needs.

As an example, consider the high structure of a symphony iin which every part is meticulously predetermined. There is no room for innovation or improvisation. The symphony is what it is and if tastes change the symphony can fall out of favor.

Compare that with a jazz quartet which is guided by a simple melody or set of chord changes. This provides sufficient structure to collaboratively innovate through improvisation. If, over time, tastes change, the quartet has room to adjust. The simple melody is more adaptive.

So, I say set a deliberate strategy and guide with principles but allow your sub-units (cluster, entities, business units) to find their own optimums through innovation and improvisation.

Join us at


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.

Friday, May 29, 2009

New Social Network for Business Architecture

Inside Business Architecture has launched a social network for business architecture. Professionals interested in Business Architecture, Business Process Management, Business Process Re-engineering, Continuous Improvement, Strategic Alignment, Organizational Design, Motivation and Business Intelligence are encouraged to join. (Did I leave any out?). Please check us out at

You will find me there.


Wednesday, May 27, 2009

SDLC and Business Obsessions: Cargo Cults and Dogma

I just finished reading Alec Sharp's excellent post On methodologies and practices. In it he referenced Ivar Jacobsen's post (on describing the fact that methodologies often collapse under their own weight, and also that we should get beyond branded methodologies and perhaps return to the fundamentals. I couldn't agree more, and was in fact making this very same point in a discussion thread on regarding TOGAF and certifications. So, Alec has inspired me to write a little more on the subject.

First, a disclaimer, I am not bashing methodologies! Much excellent work has been done over the years on advancing the practices around development methodologies. The agile manifesto was pointed in the right direction, but when I look back, I fear that the authors' intentions have, over time, suffered from two conditions: dogmatic implementation and cargo cult imitation.

The problem with "branded" methodologies, as pointed out in Alec's post, is that the adoption of methodologies is often performed with a near religious zeal (often by the novice practitioner). This is the problem of dogma. The adopting practitioner is not the founder of the method, and if the practitioner does not have enough experience to understand the intent behind a practice (or set of methods), the adoption is blind, and blind adoption is always dogmatic.

To this point, imagine the a group of students whose teacher has moved away. Their source of insight and understanding has gone. No longer can they rely on the teacher for answers. What can they do? They can turn to the teachings. There are only two ways to do this, take the teachings as law, or take them as guidance. If the student lacks the experience to interpret the teachings, they are applied with blind faith, as law, in a rigid and dogmatic style. Either way, as time marches on, the encounter of new situations will cause an instance specific - prescriptive - variation on the method - which may or may not reflect the intent of the teacher. Eventually the original teachings are lost in a compendium of epic proportion, a large and unwieldy set of rules that are so prescriptive that they lacks flexibility. Consider our own body of law - all steming from the basic principles that founded our nation.

Add to that the unending search for the best and newest methodologies (or management styles, or technologies) and the problem gets infinitely worse. We have added the problem of the Cargo Cult - what Ivar has termed as our obsession with "fashion". Cargo cults are built around the ritualistic imitation of others who have received some benefit that the cult wishes to obtain. Businesses (and technologists) are absolutely addicted to the next new thing and with today's rate of change, it is impossible to master one fashion - or determine its benefit - before the next eleven are available and touting themselves as the best thing since (insert your methodology here).

To illustrate this point, imagine an organization who has a workable methodology. It's not great, but it is getting the job done. Then, from the top of the house, perhaps due to a change in executive management, comes the order that the organization will now follow xyz methodology. This could be for any number of reasons, lets say that the CIO knows someone who has used the methodology to great benefit.

A team may be anointed and charged with implementing the new methodology. To ease the transition, the team modifies their current compendium to reflect the new methodology, making it even more convoluted and unwieldy than before, and in turn compromising much of the value of the new methodology. Time marches on, and since the new methodology isn't getting the job done, it is abandoned for the next "fashion" - with the cargo cult like hope of receiving benefits.

But it's really not as hard as all that. Back in 2002 and 2003 , while I was working on software methodologies, I was a strong proponent of a core set design principles, the fundamentals of sound practice that can be applied regardless of which methodological veneer is glued over the top I would argue most of these veneers have strong cultural bias, and one methodology is more suited than another because of corporate culture, and hence better for that culture.

Regardless, here are the basic underpinnings that work for all methodologies.

  1. Any method should be as simple as possible and adapted to need - be practical
  2. Focus activities on capital building and minimizing overhead - build value
  3. Run your project as if it were a business - because it is.
  4. Understand how the operating environment affects your methods - because they will.
  5. Stand on the shoulders of the giants - don't reinvent the wheel (but don't be dogmatic)
Not only should one adopt these principles, but a development team should have a few sound goals (other than the most obvious goal of achieving the needs of the business):

  1. Minimize complexity and exploit automation
  2. Continuously improve your methods
  3. Continuously develop team proficiency
Remember too, that practices are meant to be transcended. To may make a strange martial arts reference, we should be striving to achieve Ri, the phase of Shuhari where the practitioner has learned the techniques, tested their boundaries and forgotten them, transcending the teaching, realizing perhaps that there are no techniques, or that all techniques point to the same basic principles.

Thank you Alec for firing me up enough to write this article, and thank you Ivar for laying much of the foundation, even if the industry often looses sight.


Sunday, May 24, 2009

The Concerns of Economics (Prosperity)

In my post entitled The Framework for Organizational Fitness, I outlined the three basic concerns - or systems - of any organization, they are the concerns of Affiliation, Economics, and Learning. Today I would like to explore the most recognizable of an organization's three basic concerns, Economics.

To me, the concern of Economics is about creating prosperity, which is why I think I'm going to change it's name. I like the term prosperity because it encompasses more than just the accumulation of wealth. To me it also denotes success and achievement in ways that don't revolve around building monetary wealth and so includes charitable work and not for profits.

Whether for profit or not, an organization must provide something of value, say a product or a service, to the community at large. This is the organization's value proposition. The systems that configure, create, and deliver this value (products or services) are the systems devoted to managing the concerns of Prosperity. The delivery of value is often called throughput, a term I dislike because it blurs main objective - the delivery of value. Still, most BPM, six sigma, process improvement, lean or any continuous improvement effort such as (insert your favorite here), focus mostly on throughput, for example, driving down cost, speeding up delivery, or any other typical matter of efficiency. This focus can easily undermine value creation.

Since concerns of Prosperity embody the financial aspects of an organization, and since most public organizations live and die by the stock markets whose primary indicator of value is profit and growth, these elements are often overly distorted in importance. I know this may sound strange, but it's true. Most organizations tend spend way too much time focusing on finances. When profits, shares, and growth get overly distorted in importance, an organization can become fixated on driving down cost, speeding up delivery, or other typical matters of efficiency. Sound familiar? When this becomes the organizational mantra, it also becomes the hymn of both internal and contracted improvement efforts.

The focus on throughput and efficiencies is absolutely necessary but it is not sufficient. Perhaps even more important are the concerns surrounding Community and Learning. Without establishing a viable, trusted and inclusive community, and without a system of learning through the practical application of observation and insight - a fundamental aspect of adaptability and sustainability - an organization will get out of touch with its communities and will have no compass for the road ahead. More later.


Monday, May 18, 2009

New Online Publication: Inside Business Architecture

We have exciting news! This blog is now the companion blog to Inside Business Architecture, an online publication dedicated to the concerns of the Business Architect.

Inside Business Architecture is currently looking for:

Professional Business Architects who would like to share their insight.

Vendors who wish to promote their company through white papers, announcements or press releases.

Academicians who work in a related field and wish to reach out to the business community.

If you fit one of these categories, please contact us through this blog or at Inside Business Architecture.

Suggested Topics of Interest:

Business Architecture, Business Process Management, Process Improvement, Organizational Design, Program Management, Change Portfolio Management, Strategic Alignment, Service Oriented Architectures, Chaordic Thinking and Complex Adaptive Systems - or any other concerns that impact the Business Architect.


Wednesday, May 13, 2009

Eve and Business Architecture

So Mother’s Day has come and gone and I feel compelled to write about Eve. Not the biblical mother of mankind, or this Eve either, but the massively multiplayer online game. What does this have to do with Mother’s Day? Well, as it happens, my mother, a retired business manager, ventured – a number of years ago - into the vast emptiness of space and has become the CEO of a virtual corporation in, you guessed it, Eve.

Corporations in Eve are a rich source of game dynamics. They have CEOs, directors, and members and can distribute shares of the corporation to deserving individuals. There are a variety of goals that drive a corporation, and this shapes their approach to their game (markets). A corporation’s approach to the game, its strategic and tactical plans are often highly guarded secrets, known to only a few high ranking members. If a strategy or set of tactics becomes public knowledge, other’s in the game will try to take you off your mission.

The corporations in Eve need to be careful about who they add as members (employees) as there are slackers and spies. More importantly, if a member’s goals are not aligned with those of the corporation, they can become dead weight, become disillusioned and perhaps leave (taking valuable corporate secrets with them).

If a player shows promise and becomes a member of a corporation, the corporation often uses incentives to keep the player in the corporation, offering them perks that they could not hope to get on their own. This gives the organizational members a richer experience in the game (a better life).

Corporations can form alliances (and have enemies - competitors) with other corporations. These alliances allow the corporation to extend its reach (think integrated supply chains). Alliances have goals of their own and each corporation has a liaison to the alliance (think relationship manager).

Alliances can be friendly toward other alliances, or not. One alliance can help another achieve its goals one day and battle it the next. This is a web of coopetition as alliances make and break bonds with other alliances each in pursuit of their own goals.

It also appears that in the vastness of space, resources can be scarce. There are raw materials - a primary source of income, there are industrial resources, there are goods to be amassed and there are intellectual resources that must be acquired and appropriately managed.

In Eve, corporations also have a life cycle. Early in the formation of a corporation, you are vulnerable to misstep, mismanagement and potential dissolution (you could be betrayed, or destroyed, or you could over-reach, or under perform) there are many ways to die here. As you gain your corporate legs, you become more powerful and rather than recruiting players to join your corporation, players can start coming to you. You have good brand reputation; you are known in the universe. All this time the structure and dynamics of the organization are changing, remember that in this game, members of the a corporation are real people.

Corporations may also then, of course, join an alliance. To do so, a corporation has to give up some of its independence, but the reward here can be great, taking the corporation to another level entirely – an extended enterprise.

Corporations and alliances can age and become flabby and uninteresting and they can loose touch with the heartbeat of the game. This is a death sentence. With limited resources, too much fat, and no good idea any more about what is really happening, there is only one course of action (other than demise) and that is to reinvent and reengineer your company. You might need to become lean, shed some weight and refocus your goals, but this is a highly dynamic game and the environment is constantly changing. If you can't adapt and maintain your organizational fitness you are doomed.

I have not yet begun to scratch the surface of this rich and complex game. Perhaps later...


Friday, May 8, 2009

Six Degrees of Separation and Networks

So I just watched Connected: The Power of Six Degrees, a Science Channel show on network theory. It seems the whole thing is Kevin Bacon's fault. It is a good recap of the six degrees of separation with some pretty common sense stuff if you just stop to think about it. For example, most social networks are fairly homogeneous and rather small. These would be considered local clusters. Interconnecting local clusters has a profound impact on the transmission of information.

Most of it does seems to be common sense. Consider a native tribe using drums or smoke signals. In this way local clusters - the tribe - could signal another cluster (again tribe) about important events - perhaps the location of buffalo, or impending invaders. This kind of information transmission has been going on for a long time. Modern day examples are the telegraph, telephone, and of course the internet.

The show also discussed the importance of hubs - points of massive connectivity - and their importance, for example removing hubs can cause a network to collapse. I couldn't help but think that the television I was watching was a kind of hub. I thought about CNN and the other news channels, each of which leans this way or that, each of which feeds information from their distribution hubs into our little local clusters. Kind of a Babbit thing.

The notion of a hub, though, is not new either. Trading posts were hubs as were the first towns and cities. They were certainly larger than the local village (family) cluster! Over time they took on ever important roles, stripping the family cluster of it's independence, and perhaps even lording over the clusters (families) within their reach.

The list is endless, universities are hubs of learning, a nation is a cultural hub, and so on. An organization is certainly a hub, a center of activity that, as we have seen lately, can disrupt many clusters (again families) if it runs itself into the ground.

There are an interesting implications to self organization and adaptability. When the connections between the nodes of a network are too low, the network is overly stable and while stability seems like a good thing, it isn't when adaptability is required. Self organization and adaptability seems to occur spontaneously when all the nodes of a network have two connections.

In such a network, the number of possible states is 2^N or two to the power of N where N is the number of nodes in the network. In large networks the number of possible states can be staggering. The thing here is that when the connections is equal to two, a system settles into a relatively few number of states (behavioral patterns), which approximates the square root of the number of nodes. This is self organization. These systems are adaptive and able to withstand perturbation through reconfiguration.The classic example cited is DNA.

Our DNA has, perhaps between 65,000 and 75,000 genes. The number of possible states is 2^100,000 (a very big number). If we take square root of 65,000 (our self organizing pattern equation) we have just 256 possible states for our DNA to assume. Biologists tell us that we have somewhere around 250 or so cell types. Not too bad.

Anyway. I need to noodle on this more because as we all know social networks - facebook, myspace, and linkedin, to name a few, are all perfect examples of networks with local clusters and massive hubs.

Watch the show, its on one more time.


Tuesday, May 5, 2009

Organizational Fitness Chapter 1: The Effects of Structure

For this installment, I put together a presentation on The Effects of Organizational Structure that briefly outlines:

  • Structure
  • Performance
  • Context
  • Change Dynamics
  • Structure and Dynamics


Friday, April 24, 2009

The Framework for Organizational Fitness

I would like to invite you all to review and critique this linked > framework. It represents, at a high level, the outline that I will be evolving over the next few months. It is comprised of the three areas of concern within an organization, Environments, Lifecycles, and Fitness.

Here is a brief synopsis of these areas of concern:

Organizational Fitness can be measured and manipulated with respect to one of three core systems.
  • Learning systems, which I touched upon in my last post
  • Affiliation Systems
  • Economic Systems.
I will cover these systems in detail in later posts.

Environments contributes to Organizational Fitness by providing operational context. The overwhelming environmental factor that affects how to approach organizational fitness is its dynamics. As the dynamics of an environment change, perhaps due to lifecycle, the operational context changes, and fitness can change.

Lifecycles is often overlooked but should be considered as a primary force that shapes a solution. Gartner's hypecycle is an application of lifecycle to technologies. Different lifecycle stages constrain solutions differently. As something matures, the same problem may require different solutions - and different approaches.

More to come. Cheers.

Wednesday, April 15, 2009

Learning Systems

In writing my latest article (to be published in May), I spoke indirectly about the organizational mind. There, I was laying out the three core systems of an organization with respect to Organizational Fitness. One of those systems is the Learning System. Its two main sub systems are the observation systems and learning systems. What struck me was how important the learning system is to an organization's world view.

How an organization tunes the observation systems dictates how much and of what it perceives. The learning systems (which include the tacit learning discussed previously) help an organization interpret and prioritize the observations by fitting them in to the current world view, and perhaps adding to it or modifying it to some degree. Differences of focus, quality, maturity, and completeness of these learning systems can, for the exact same operating environment, provide completely different world views.

Since an organization's world view shape strategies, objectives, execution and programs of change, the differences in the learning systems can highlight why some organizations are better able to navigate their operational environments than others.

The real question becomes this; how do you tune observational and learning systems to help navigate highly dynamic environments where ambiguity, complexity and unpredictability are the norm?



Friday, March 20, 2009

The Organizational Mind

The organizational mind is a unique structure, composed of both tacit and explicit elements. It is directly related to competence and closely related to capacity and capability. The tacit elements are contained in the minds of the members of the organization where the explicit elements are part of the organizational memory. Why is this important? Tacit minds can walk. They are borrowed, or more properly rented, by the organization and form a symbiotic relationship with the organization. The explicit mind belongs to the organization. It use to be captured on paper, but in today's world the strength of the explicit mind is in the use of automated agents. In reality, much of the organizational mind is tacit and much of what is explicit is still randomly captured in fragmented bits ranging from paper records to excel files to fully automated intelligent systems. Still, this is the organizational mind and its structure has a profound effect on the adaptability and sustainability of an organization which I will explore in another post.


The Business Architect

Monday, March 16, 2009

Best Intentions vs Organizational Reality

After reading yesterday's post, I started thinking about why an organization might exhibit such inappropriate behaviors when - and we will give the benefit of the doubt here - all of the people that comprise the organization are bright and well intended individuals. Putting an employees personal goals aside for a moment, this has to do with the complexity of an organization. At the point where an organization becomes sufficiently complex it can, and most likely will, start to exhibit unintended behavior - emergent behavior. When an organization is too large to be comprehended by a single mind - and most are - or when a persons sensors aren't trained to detect these emergent behaviors, and this is often due to improper incentives, then these behaviors fly mostly under the radar, at least until they become so problematic that someone takes notice. (This is not to say that all emergent behavior produces disharmony in the mind, body and soul of an organization, just that it might).


The Business Architect

Sunday, March 15, 2009

An Organization's Mind, Body and Soul

There is only one thing that you need to do to develop a successful business architecture, harmoniously integrate the mind, body and soul of an organization. Since organizations can be complex, nested, political, ineffective, inefficient, inconsiderate, entrenched, stupid, aimless, fat, and slow, and since the environments in which they operate dictate - or at least shape - the requirements for success, this is no easy task. But still, I contend that all you need to do is that one thing. This then should be your goal, the harmonious integration of organizational mind, body and soul. Everything else flows from this.


The Business Architect

Saturday, March 14, 2009

The Business Architecture Project is Launched

Hello and welcome the The Business Architecture Project. Over the coming months, I will explore the structure, function and execution of an organization in terms of its decisions, operating environment, and life cycle. I will also be exploring how a business bent on success, adaptability and agility most often follows a slow and deliberate path to its own obsolescence. If these things are of interest to you, follow my blog or check back in once in a while.


The Business Architect