Search Results for: business model

Understanding Business Services 2

by

In December 2006 I blogged on the topic of Explaining SOA to the Business Audience. It started out “I note resurgent interest in LegoTM blocks as a metaphor for explaining to the business audience the value of SOA. My advice is don’t treat the business audience as dummies!” The blog goes on to explain business services using the Laundry metaphor, and how business people get the concept because they understand “services”.

However, while my explanation was and remains perfectly OK, I will be the first to admit that I have moved on. The basic service model works perfectly, but in today’s fast moving, business innovating world, we need new vocabulary that is even more compelling, that goes beyond SOA and transactional efficiency.  

In their book Competing for the Future [1], Gary Hamel and C. K. Prahalad advise that traditional business responses to market and competitive pressure such as reengineering, downsizing and outsourcing are inadequate and insufficient. The outcome of this activity is typically just keeping one step ahead of declining margins and profits of yesterday’s business. Instead senior management need to get off the treadmill of restructuring and reengineering and instead reinvent their industry, imagining and creating their future.

What I didn’t say in 2006 was that you don’t reinvent an industry by analyzing business processes! The business process is “how” the enterprise works. Instead we need to be looking at “what” the business is – business services, the external, composite offering that enables core capabilities to be used in many different contexts. We need to elevate the concept of Business Service to the level of business offering and business product that externalizes the enterprise capability. I suggest simple definitions as follows:

Business Service: A service provided by an enterprise to its ecosystem of customers, suppliers or partners that provides one or more capabilities that facilitate a discrete business outcome according to a contract.  Example: Amazon EC2 
Business Service Operation: An execution of one or more capabilities provided by an enterprise to its ecosystem of customers, suppliers or partners according to a service contract. Example: Data load under Amazon EC2.

In Table below I have summarized some of the Hamel Prahalad strategies and shown how these are implemented as Business Services.

Hamel and Prahalad go on to pose the question, “Why did it take US automakers 40 years to decode the principles of lean manufacturing pioneered by Toyota?” Answer – because those principles challenged the core assumptions of US auto executives.

I suggest we need to establish a business centric perspective of Business Service that is as closely linked to business offering implementation as it is to the internal SOA. This will cause us to challenge some of our core principles and assumptions. It’s NOT about LegoTM, it’s about business services and business agility.
[1] Gary Hamel and C. K. Prahalad , Competing for the Future, published by Harvard Business School Publishing, Reprint 1996

The Business Architect’s Service Portfolio Part Five: Designing the Portfolio

by

For some time now I have been promoting the idea that the practice of business architecture is not about creating blueprints and models but applying a set of tools and techniques to form broader perspectives, create deeper insight, and solve business problems. If business architecture is a practice then what is its portfolio of services? […]

Understanding Business Services

by

A business service represents an agreed delivery of some parcel of capability from one agent to another agent.

Understanding services properly requires a combination of all six of the viewpoints I have defined for business architecture.

The capabilit…

3 steps to free your business from the IT stranglehold (and vice versa)

by

It’s not just IT that slows down the business. In a recent study 20% of companies reported they have NO innovation strategy and more than 50% of companies reported that their innovation strategy was mis-aligned with their business strategy and that their culture poorly supported it [1]. However, if we look at the IT side of an organization we often see the same kind of figures: 70% – 80% of IT budget is used just to run and maintain existing apps [2]. Maybe that’s even explainable since starting a new IT initiative is often a bumpy road: 68% of all new software projects are NOT successful [3].

These numbers aren’t new. Why do we all know them and, yet, they seem to stay the same? The interesting thing is that business nor IT is denying the current state-of-affairs. IT and business are equally frustrated about the current situation in most companies. When asked “are you happy with how IT is proactively engaging with Business Leaders to drive innovation?“, 74% of the non-IT execs state they are unhappy and 70% of the IT execs [4].

It seems like it is time for change…

I think the next 3 steps will provide a way to really change these numbers…

Step 1: start to believe in an agile enterprise

It wouldn’t be strange if you accepted the status quo: change is difficult, change is slow, especially in a big company. However, that’s not how it ought to be.

I believe that successful Enterprises:
Are agile.
Can respond quickly to changes in the market.
Because all departments are fully integrated in the overall value stream.
They have a big vision, but operate in small steps.
And gather feedback continuously and early-on.
They always work back from the customer and let customer-value drive new initiatives.
They focus on eliminating everything that’s not contributing to the value stream.

I believe that such Enterprises need Apps:
Flexible and focused apps.
That perfectly fit the business.
They are easy to find.
And easy to access, from any device.
They have an integrated user experience.
Their lifecycle is agile.
They change along with the business.
Users are engaged and their feedback is processed fast.
New apps are build in a collaborative process involving all stakeholders.
And they are easily delivered to the selected user base.
They align with enterprise needs around security, integration, and governance.
Instead of slowing the business down, they drive business innovation.

Utopia?
“Live your beliefs and you can turn the world around.” (Henry David Thoreau)

Step 2: add a ‘new productivity platform’ to your enterprise architecture

If we really want to change the way IT supports the business, we need to change the way we build new apps and manage the lifecycle of apps. Most IT teams are struggling with the amount of work they have, often resulting in a “no” to the business if they demand new business functions provided in software. And let’s just not talk about the constant change of business processes and policies that need to be reflected in existing software.

According to Forrester analyst John Rymer, Java and .NET are often no longer the best choices for the fast delivery of new business applications. Instead, we need, what he calls, new productivity platforms, to speed-up initial application delivery and ongoing updates. He defines “new productivity platforms” as [5]:


Platforms that speed application delivery and ongoing evolution through: visual tools, hot deployment and continuous innovation, built-in administration and management, and active participation of business experts in application delivery.

In my view these platforms are a special breed within the Platform-as-a-Service (PaaS) category. I’d like to call this sub-category Application Delivery PaaS to emphasize the focus on the complete application delivery lifecycle and not just deployment (as unfortunately a lot of PaaS platforms do).

The App Delivery Lifecycle


Figure 1 – The App Delivery Lifecycle (source)

Figure 1 shows the four important phases in the application delivery lifecycle. The phase at the top is about requirements capturing as a collaborative process among all stakeholders. This collaboration is continued in the next phase when the new ideas and requirements are converted into models (or existing model templates are selected to fulfil the wishes of the stakeholders). In this phase the focus is on highly productive, collaborative development using visual models. These models are 1-click deployed to a runtime environment where they are executed and become real apps (I dubbed this Model-Execution-as-a-Service in the past). The key in successful app delivery is to continue to the next phase and engage with users, listen to their feedback, and use that feedback to come up with new requirements, thereby continuing the next cycle.

The phases are not numbered on purpose. The only way to really improve app delivery is to create shorter feedback cycles to increase collaboration with all stakeholders within an app delivery project. Where you start doesn’t matter, the app delivery lifecycle is a continuous process in which each cycle is as short as possible. And yes, this process should fit in an overall agile process to be able to function in the way described above. Or, in other words: the agile process needs to be extended outside development, we could call this ‘enterprise agile‘.

In my opinion you should start to use an Application Delivery PaaS. The ‘agile enterprise’ as described in step 1 will become much more within reach.

Step 3: know what’s agile and what’s not

If you are an enthusiastic user of one of these “new productivity platforms” (an Application Delivery PaaS) you may think this is the way to go for all application development. Something along the lines of “if all you have is a hammer, everything looks like a nail” [6]. Don’t go that way.

These platforms aren’t good for everything. Their real value shines when used for applications that need to be agile, that change on a weekly or even daily basis. You probably don’t want to build your bookkeeping software from scratch using such a platform. You should look at your processes and applications and distinguish different categories. Gartner distinguishes between commoditized processes supported by commoditized applications (e.g. bookkeeping software in most organizations) and differentiating processes supported by differentiating apps. Differentiating processes are the processes of your organization that really distinguish you from your competition. These processes will probably change frequently and time-to-market is important.

Ron Tolido (CTO at Capgemini) describes it way more colorful in his whitepaper about the five different application lifecycles that address different IT dynamics in organizations [7]. He uses a transport metaphor to identify these five different application types:

  • Trains: stable, robust, standardized, no customizations, lots of users.
  • Buses: also relatively stable, but more flexible. Some organizations may choose to own or hire their own buses.
  • Cars: much more agile, individualized means of transport. Owners will adapt and configure them.
  • Scooters: lightweight, extremely flexible and individual method of transport. They can bring you anywhere and you can even rent them for just a day or so.
  • The hub: connecting the above.

You need to address each of these application types in a different way. In short: buy standardized solutions for trains and buses. Build apps using an Application Delivery PaaS if you need cars and scooters.

Conclusion

To summarize:

  1. start to believe in an agile enterprise, 
  2. add a ‘new productivity platform’ (an Application Delivery PaaS) to your enterprise architecture, 
  3. and know what’s agile and what’s not.

If you do so, I’m sure the numbers mentioned in the introduction will really start to change!


——————————-

[1] Booz & Company – 2011 Global Innovation 1000 Study

[2] “In IBM’s experience, the 70-80 percent figure is roughly correct; little funding is left for innovation” https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/enabling_smarter_decisions?lang=en

[3] Chaos Report 2010 by the Standish Group

[4] McKinsey Quarterly Dec 2011

[5] John R. Rymer, The New Productivity Platforms: Your Solution To The AD&D Crunch. November 1, 2011.

[6] Abraham H. Maslow, The Psychology of Science, p. 15, 1966.

[7] Ron Tolido, From Train to Scooter – Five Application Lifecycles That Address Differing IT Dynamics Within Your Organization, 2011. http://www.capgemini.com/insights-and-resources/by-publication/from-train-to-scooter/

3 steps to free your business from the IT stranglehold (and vice versa)

by

It’s not just IT that slows down the business. In a recent study 20% of companies reported they have NO innovation strategy and more than 50% of companies reported that their innovation strategy was mis-aligned with their business strategy and that their culture poorly supported it [1]. However, if we look at the IT side of an organization we often see the same kind of figures: 70% – 80% of.

The post 3 steps to free your business from the IT stranglehold (and vice versa) appeared first on The Enterprise Architect.

Enable Cloud Strategy and Planning with Predictable Methods, Models, and Tools

by

We previously looked at why cloud is so important (Challenge the Status Quo and Advance Business through Cloud Computing, ), approaches to cloud strategy (Understanding Which Investments Should go to the Cloud, Cloud Strategy Begins with Value and Balances Risk…

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 
It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 
The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 

It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 


The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

The Business Architect’s Service Portfolio Part Four: Project Support Services

by

For some time now I have been promoting the idea that the practice of business architecture is not about creating blueprints and models but applying a set of tools and techniques to form broader perspectives, create deeper insight, and solve business problems. If business architecture is a practice then what is its portfolio of services? […]

Business Performance Management, the next big thing…again

by

We all possess the gene to want to solve problems when faced with them. It’s human nature. People form organizations and this gene sometimes manifests itself in organizational titles and roles invented to address organizational challenges. This i…

Categories Uncategorized

Business Performance Management, the next big thing…again

by

We all possess the gene to want to solve problems when faced with them. It’s human nature. People form organizations and this gene sometimes manifests itself in organizational titles and roles invented to address organizational challenges. This is natural too. For example, when support organizations face the challenge of aligning to business organizations, we see…

The Business Architect’s Service Portfolio Part Three: Organizational Change Services

by

For some time now I have been promoting the idea that the practice of business architecture is not about creating blueprints and models but applying a set of tools and techniques to form broader perspectives, create deeper insight, and solve business problems. If business architecture is a practice then what is its portfolio of services? […]