Reorganization of a business is not easy. Following the usual process of organizational design, you work to identify the current organization, note the gaps and describe a process for getting to the new organization. That sounds easy enough in theory, but implementing the reorganization is not nearly as straight forward. Asking stakeholders what the problems are usually only gets you symptoms. Identifying gaps is difficult because if the organization knew there were gaps, they would have fixed them. Then you have those who abhor change who believe their area of the business works fine – it’s everyone else’s fault.

Getting Started

Reorganization of a business is not easy.  Following the usual process of organizational design, you work to identify the current organization, note the gaps and describe a process for getting to the new organization.  That sounds easy enough in theory, but implementing the reorganization is not nearly as straight forward.  Asking stakeholders what the problems are usually only gets you symptoms.  Identifying gaps is difficult because if the organization knew there were gaps, they would have fixed them.  Then you have those who abhor change who believe their area of the business works fine – it’s everyone else’s fault.

Getting Started

In a recent discussion with a colleague, the relevance and effectiveness of Business Architecture artifacts like capability maps, value streams and organizational maps were the topic of discussion.  His belief was that these artifacts were just a way to do drawings that document what has been done.  I might add that he is a disillusioned Enterprise Architect, as most of the projects he was assigned just needed him to document the project result in TOGAF or DoDAF.

How many of you have heard the statement “The project failed because we didn’t have good requirements”? I’ve heard it dozens of times. It doesn’t matter whether it’s from seasoned project teams or ad hoc teams. The single biggest reason for project failure is a problem with the requirements. Even with agile processes in place, I see the same things repeated over and over. In doing post-mortems on projects that failed and projects that succeeded I have found some common traits.

Most entrepreneurs understand the meaning of a “Pivot”. A Pivot is a change of direction for the entire organization in order to take advantage (or find) an opportunity that expands the company’s business. A pivot can create an atmosphere of what appears to be total chaos and without proper management, can leave a business slogging along instead of soaring higher. However, by understanding the capabilities of your company, capability maps can make pivots more manageable. A pivot is one of the few times where capabilities may become fluid in order to adapt to the new direction. Business architecture usually assumes that capabilities are relatively stable – not so with a pivot.

During the recent assessment of an organization, the topic of CM popped up as a reoccurring theme when it came to problems being experienced throughout the organization.  The one thing that became exceedingly clear was that everyone’s definition for CM was very different.  One of the prime roles for any business architect is to make sure they are looking holistically across the organization and that everyone is working from the same vocabulary.  This is not the first time I am running into the topic of “CM” as a source of chaos.

In this world of “It’s not my job!” thinking, I look at the practice of business architecture and noticed that nowhere does anyone discuss business requirements as part of business architecture.  “We are not IT, we are aligned to the business.” Yet, one of the values of business architecture is to create the bridge between business and IT which means at some point we need to be involved in translating business requirements or business needs.