Business Capability Redefined According to SMACT

Comments: 4
Rate this:
Total votes: 0

Innovate or die. That is the mantra of successful organizations that compete in a fast-transforming digital world. Those who harness social media, mobile, analytics, cloud computing, and Internet of things (SMACT) to digitize the business win in the marketplace. Those who don’t, lose. It is a wild, wild digital world out there.

Business architects embedded in successful organizations need to innovate as well or lose relevance. The world where business architecture matters has changed. Old paradigms give way to the new. One area that needs rethinking is how business architects define a business capability.

How often do we hear or speak of a business capability as an encapsulation people, process, and tools?* How we arrive at this description is understandable. It follows the paradigm that traditional enterprise architects use to frame their thinking. Enterprise architecture describe frameworks as layers that sit on top of each other to illustrate that each layer builds upon (and depends) on the layer or layers below or above it (see figure 1). Based on this framework, what a business (or non-profit organization) does can best be described as an assembly of people who perform processes enabled by tools.

Figure 1. Business capability as layers

The business architecture layer drives the underlying layers of information, application, and technology architectures. For true alignment, the underlying layers feed back business results to inform the business architecture. This relationship works in a linear and predictable manner where the handoffs are clear. One part of the organization is responsible for each layer and most probably uses specific tools to perform the prescribed processes.

In today’s digital world, this concept is becoming passé. Is it not time to reframe our thinking to reflect the realities of our time?

Our world today is non-linear, unpredictable, and the lines separating silos disappear. The most successful organizations operate not in isolation but in a web of relationships. These organizations operate in a modular and agile way to manage complexity.

The new paradigm challenges this limited view of the enterprise. A business capability is no longer just an assembly of people but of humans and machines. A business capability is no longer just a set of processes; it is about business outcomes. A business capability is no longer just about tools. It is about the Internet of things. A business capability, therefore is still an encapsulation but of humans, machines, things. Each work together in a web of relationships and in harmony to produce business outcomes (see Figure 2).

Andrew guitarte2

Figure 2. Business capability redefined by SMACT

Business architects almost always encounter SMACT in every engagement. For example, in a recent meeting about rationalizing applications, a client brings up the topic of cloud computing and social media applications as another set of applications that the company needs to govern. In another meeting about optimizing investments in technology-enabled projects, a CFO asks how the company invests in analytics and business intelligence to improve sales and operations.

As the world changes where business architects operate, so must business architects adapt. The old notion of a business capability as an encapsulation of people, process, and tools no longer captures the essence of a digital world. A business capability is by necessity more dynamic and complex. It involves humans, machines, and things working together to produce an outcome. It is time to let go of what is passé and time to embrace our brave new digital world.

Footnote: * Ulrich Homann writes in an article titled “A Business-Oriented Foundation for Service Orientation” a formal definition where “a business capability abstracts and encapsulates the people, process / procedures, technology, and information into the essential building blocks needed to facilitate performance improvement and redesign analysis.”

Comments

Mark Goetsch
,
posted 7 weeks 4 days ago
This is the wrong paradigm for architecting businesses. Veblen defined the business enterprise through its effective integration of people, processes, and technologies. Effectiveness at the enterprise is not the same as being profitable in business. The latter is well understood in business and defined through the various vertical functions of the organization that lead from raw materials to finished products that are distributed and sold. The former, however, was first conceptualized by Chandler, who noticed that there was an enterprise dimension around the economies of scale and scope that enabled one business, with the same exact vertically integrated structure, to outperform another. He saw three factors, management, economies of scale, and economies of scope, which were factors of the enterprise. It was in the work of Coase in 1934 that the enterprise and business are integrated together as part of reducing transaction costs. This was perfect for the world of manufacturing. In 1976 G.B. Richardson noticed that the world had become more complicated that what Coase had predicted. The world of services went beyond the functional model and the separation between the firm and the market. He used the term capabilities as a way to pull together the product and service views. In general terms there are assets that firms pull together as competencies which the organization uses to determine its positioning. These are combined together into capabilities that enable the firm to have a competitive advantage that includes not only products, but the partnerships, ecosystem, and connections with customers and clients.
Roger James
,
posted 7 weeks 5 days ago
"A business capability (or simply capability) describes a unique, collective ability that can be applied to achieve a specific outcome. A capability model describes the complete set of capabilities an organization requires to execute its business model or fulfill its mission."
This is just one definition (from the OMG). There are others. They nearly all have one thing in common though - they are implementation independent.
So SMACT is irrelevant to capabilities. The relevance (if any) comes in when you map the capabilities to whatever is required for implementation. Two different things.
I was surprised that the distinguished Mr Homann would formulate so poorly, so I looked up the original article. It seems that for the purpose of the discussion (his words) that he was proposing two different definitions for "capability" and "business capability".
The key to his thoughts seem to lie in this quote - "These business activities, which we refer to as business capabilities..."
Oh dear !!!
Chris Pehura
,
posted 8 weeks 12 hours ago
Every model we use is a reflection of our perception and history. In the world of innovation we must learn more, meaning we need to mature our models. In our research we find that successful models always around deeply rooted in: 1. leadership & culture
2. business and financial outcomes
3. systems
4. cash flow All successful models have attributes of this, including the model in this article. The big problem is that the attributes are not at a high enough priority, such as culture and leadership.
Mahendra Dharanikota
,
posted 11 weeks 1 day ago
Good Article!! I think, along with the four dimensions of Business capability, we should consider the Technology as an encompassing factor.

Join the Discussion

Your email address will remain private.

Shopping cart

View your shopping cart.

Editorial DIrectors

Gregg Rock
Gregg Rock
Editor & Founder
BAInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Related training courses

BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

Establishing Business Architecture Governance and Centers of ExcellenceBA 101Building a Business ArchitectureThe Business Architecture PlaybookBusiness Architecture / IT Architecture AlignmentView the Learning Path for more courses »