In business, as with life, you can’t do everything and of the things you decide to do, you can’t be the “best” in every facet. Resource constraints lead to competency trade-offs which require businesses to make tough decisions regarding the expenditure of time, money, and human capital. When weighing such opportunities, a business should first understand its capabilities. Truly understanding a businesses’ capabilities means much more than the identification of said capabilities. Mapping out the future-state of a business will allow an organization to categorize capabilities into three buckets: Strategic, Core, and Enabling.
Business architects are largely on the wrong track. They are focused on how to create a well-structured business architecture instead of how to create well-architected organizations. What is our mission, our goal? It isn’t to build a blueprint of the organization and it isn’t to describe our organization’s operating model in terms of capabilities and processes. Our mission, if we choose to accept it, is to architect organizations for long-term success and sustainability. That requires much more than capability maps and value streams. At a minimum, it requires an engaged and motivated workforce.
Which is more important to your organization’s success: people, process, technology, or information? Yes, I know, they are ALL important but the question is which is most important. Hopefully your answer is “people”, but do you really believe it? I see process centric architectures, technology centric architectures, and capability centric architectures. What I don’t see however are people centric architectures. The question is why? If people are our most valuable resource, if they are the most important element in business success, then why aren’t we placing them at the core of our architectural efforts?
An enterprise organizational chart of the entire management team. I assume most of you have this or at least can get a view from your HR department. Organizational charts are easy to create but don’t offer much value from an architectural perspective.
A function model. Similar to an organizational chart but listing the functions performed by each team. Once you have this, it is fairly easy to map to your capability and value stream models.
A competency model. While a function model describes what people do to fulfill the mission, the competency model describes what people are capable of doing. This seems essential to me when designing change initiatives but we seem to totally ignore potential in all of our models.
A network diagram. A network diagram describes how people (or functions) in the organization communicate outside of the formal process structure. You might also think of this as a relationship diagram depicting the informal relationships among individuals and teams.
A context model. A context model describes the way the organization is designed to work and might include such items as values, management style, incentive systems, motivation efforts, and the external and internal pressures currently being exerted on the organization.
A culture model. A culture model describes how the organization really does work. Sometimes it is working as designed but most often it is not. Everyone knows how powerful culture can be but almost no one has a model that helps them understand what their culture means to change initiatives.
The bottom line:_________________________________________________________________
Building a people centric architecture, or at least having a strong people centric view within your architecture, will be the defining element of business architecture success in the future.
Rear Admiral Grace Hopper once said the most dangerous phrase in the English language is “we’ve always done it this way.” The reality is that there are many processes and structures in a business organization that exist the way they are simply because someone set them up that way and they were never changed. There are many examples of this: approval processes with unnecessary levels of approvers and mainframe screens for operational systems are just two instances.
Many younger employees in today’s workforce grew up with computers both at home and at school. They typically utilize the latest technology for their schoolwork and in their personal lives; therefore, it comes as a shock to them when they enter the workforce and must often relearn green screen technology that they thought they left behind twenty years earlier. In other words, they encounter their first workplace reality – businesses can use some incredibly archaic technology. Large corporations continue to use legacy systems for one primary reason – it still “works” and change is uncomfortable. Upgrading a major system can be daunting and can cause breaks in business continuity.
I remember watching a television advertisement almost twenty years ago where someone took their laptop out on the high dive to do some work. The idea was novel at the time – a computer that could go anywhere because of its battery! Twenty years later we have advanced so much farther (are you reading this on a smartphone?) and not just personal laptops, but business uses as well.
As Business Architects progress through the Strategy to Execution methodology they eventually arrive at a point where they must create projects to close the capability gaps they have identified. WorkFit enables users to create new project proposals within an existing project portfolio or simply add the new project in the idea pool.
I was asked recently “what does it take to be successful Business Architect?” As an early contributor to the profession (The Capable Company: Building Capabilities that Make Strategy Work) here’s some observations on consultant and client teams.
Thank you to everyone who attended the Capabilities Demystified Webinar Series. The turn out was wonderful. Many of the attendees provided great questions that made it easy to pick this months WorkFit Round-up topic. During the WorkFit Demo session we received several questions targeted at Capability Assessments. So we thought we'd recap on the key points and product functionality to address those questions.