2 years, 29 days ago

Digital Transformation Hub – Realizing the Shared Economy

Last week I mentioned to one of my US based colleagues that I would be out of office for three days at the Irish National Digital Week (NDW16), taking the opportunity because the event was being held in Skibbereen, just a few kilometres down the road from my home office. He asked, “Surely an event of that type would be held in Dublin?”  And I replied, “Well there’s a story here that needs to be told; one that will have profound implications for business in Ireland and probably internationally”.

Skibbereen is a small market town in the South West of Ireland. The population is approximately 2000, although there’s perhaps several times that number in the immediate hinterland. It’s not an easily accessible area, you get there by going to Ireland’s second city Cork, and then taking pretty dreadful roads for some 100 kilometres. However the general area is reasonably well known as West Cork, a remote but ruggedly beautiful part of Ireland beside the Atlantic, with peninsulas reaching out into the ocean attracting sailors, divers, kayakers, cyclists, walkers and artists from Ireland, the United Kingdom, America and Germany many who visit, some who make their home here. A cosmopolitan populace that blends indigenous folk and blow-ins in a close knit community. Think of Northern California but 5 degrees cooler.

Over the years numerous leaders in business, technology and the arts have moved to the area or established holiday homes. In 2015 some of these individuals together with local business people established an initiative using private investment to create a digital hub. Notables in the group operating on a pro bono basis include David Puttnam, well known film producer and Ireland’s Digital Champion, Anne O’Leary, CEO Vodafone Ireland, Ronan Harris, VP Sales & Ops Google Ireland and John Field, Director of local retailers. John Field made a suitable building available, once a cinema and latterly a bakery, as the physical presence. Vodafone, in the (ESB/Vodafone) SIRO partnership provided a 1 Gb network, for the hub building and the entire town.  In late 2015 the Hub building, named Ludgate after a 19th Century Irish designer of an analytical engine, opened coincident with the co-located 2015 National Digital Week event.

Last week, the NDW 16 event was once again held in Skibbereen, attended by some 1600 delegates from all over Ireland with 70 speakers and 2 arenas. Speakers included big names such as Google, Paypal, Uber, AirBnB. But what is really interesting about this event is that in spite of the “digital” theme, most of the sessions were about applications, people, collaborations and experiences.

West Cork, like most of Ireland has extensive farming interest. A session that resonated with me was the speaker that showed an image of an obviously recent, top of the range model combine harvester, who quickly went on to show an even newer harvester image, asking the question, “why would I replace a great piece of machinery so quickly, particularly in an uncertain economic climate?” And he proceeded to show the direct cost benefit of the newer model that with GPS guidance and yield data analysis enables huge improvement in cropping precision, efficiency and yield. I never did get to ask when the driverless combine would be available, but we can probably assume it’s not far away. The speaker also commented that this level of technology is fully in production, available to and easily usable by farmers today, and doesn’t just collect big data, but integrates with farm management to instruct fertiliser, treatment and cutting programs. The net effect is to de-skill the farm management task and improve the consistency and quality of outcomes.

Although very impressive, in many ways this farming case study is actually quite ordinary. It’s an application of digital technology that extends existing practices for improved cost benefit. What really caught my attention was the series of presentations on the “sharing economy”. Naturally there were presentations from the big names like Uber and AirBnB, both expressing concerns about government action or inaction preventing growth. For AirBnB certain cities came in for criticism. Uber asserts the Irish government is effectively protecting the incumbent taxi drivers and preventing rollout. Given both firms are very persuasive on the opportunities to create bigger marketplaces and, in the case of Uber, positively impact emissions, I wondered whether both firms would be better served if they worked with unions and governments to demonstrate how the business model and technologies could be used to extend, improve and integrate the old and new.  Maybe using smaller environments such as Skibbereen or Cork to act as exemplars, rather than taking the more confrontational approach casting the incumbents as Luddites.

A really instructive session introduced a seriously mundane application from Kollect, a local rubbish collection operator that has established a digital business offering “on-demand, pay as you go” rubbish collection. The householder uses a smartphone app to communicate his or her instructions for pickup when the bin is full. Kollect then coordinate the request to third party waste disposal companies who make the pickup. You might say a variant on the Uber model for rubbish collection that claims to reduce collection costs by up to 40%. A big deal in Ireland where bin charges are often highly contentious. This demonstrates like nothing else the pervasiveness of digital opportunities.

A similarly instructive session came from a very impressive Dublin not for profit organization, Food Cloud. They started in an incredibly small, local way to try to address the huge amount of food wasted in the retail supply chain by redistributing to worthy causes. Initially they enabled small businesses to communicate leftovers and collection times at the end of the day by smartphone app and then establish demand from charities. This simple idea has been picked up by food giants like Tesco who have integrated the concept into their own instore systems to make donation part of their core process, and now has grown into a significant operation redistributing food from over 1000 stores to over 3000 charities in the UK and Ireland. Here we see digitization enabling collaborative processes operating for the public good, while reducing costs for the retailer.

Anne O’Leary, CEO Vodafone Ireland spoke about how Ludgate is a focal point for digitization in West Cork and how firms have embraced the concept. Larger Dublin based tech firms are now facilitating employees to work remotely out of the hub; smaller, local firms are setting up in the hub to have access to the hi-speed network facilities. Overall the hub is seen as a great success and delivering on the promise of supporting up to 75 people in the creative co-working environment with the long term objective to create 500 direct jobs and 1000 indirect jobs via a sustainable digital economy for Skibbereen and the wider West Cork area. She went on to say that the SIRO partnership views Skibbereen as a prototype, and is now planning a further rollout to establish 50 hub towns across Ireland.

The following day I was sitting in my kitchen with a neighbour – a lecturer in horticulture. He told me he has a project in progress to plant two thousand and twenty apple trees in and around Skibbereen by the year 2020. The idea being to introduce a greener environment with pervasive blossom in the Springtime, adding to the charm of the town. He is harnessing the enthusiasm of his students to identify the sites, make agreement with owners, to clear the ground, plant, nurture and critically to collect data. He plans to collaborate with digital folk in and around the hub to develop an app and website that will monitor and manage the project, and to establish a research base for different varieties of tree, tracking and publishing crop data that will be of great interest to apple growers everywhere. An outstanding example of how the hub is encouraging students in non-technical disciplines to engage with digital transformation, increasing their understanding of horticulture science by using big data techniques for improved plant management, while improving the environment for everyone.

Notwithstanding the “digital” branding, the NDW16 event was actually little to do with technology; it was all about application of technology and the ability of the new technology platforms to support collaboration of multiple parties. The digital hub clearly acts as an accelerator. The network and technology enabled working spaces facilitate new businesses, new business models and improved remote working conditions for larger companies. But the real digital transformation occurs as non-technical individuals and teams apply their current skills and expertise to leverage the technology and develop new improved business models. And the opportunities for new and existing businesses, not for profits, informal groups and individuals, in fact everyone are unlimited. Simply put, the maturity of the technology platforms is such that we should expect the digitization of pretty much everything we do or engage with, will happen very rapidly over the next few years. Of course change isn’t always comfortable for everyone, and the AirBnB and Uber examples remind us that new business models must address sociological impacts. But as the de facto foreign direct investment model in Ireland comes under pressure from political earthquakes in the UK and USA, the idea that Ireland could rapidly grow significant indigenous capability doesn’t seem impossible. Finally, it must be noted that this initiative has been achieved without government support, by voluntary effort, private investment.

4 years, 7 months ago

Not Another Framework? Part 2

In my last post Oh No! We need another Practice Framework,  I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.

I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.

Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.

The objectives of the framework are to:

– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality

Principles are foundational for any framework. 

Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.

Capability Model

In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?

If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]

In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management.  So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.

Most of the capabilities in the model are self-explanatory. However some need explanation:
1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration. 
2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles. 
3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality. 
I will detail all the capabilities in a subsequent post.

Final remarks. 

This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment  . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post. 
                  Beware the New Silos
4 years, 7 months ago

Not Another Framework? Part 2

In my last post Oh No! We need another Practice Framework,  I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.

I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.

Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.

The objectives of the framework are to:

– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality

Principles are foundational for any framework. 

Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.

Capability Model

In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?

If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]

In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management.  So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.

Most of the capabilities in the model are self-explanatory. However some need explanation:
1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration. 
2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles. 
3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality. 
I will detail all the capabilities in a subsequent post.

Final remarks. 

This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment  . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post. 
                  Beware the New Silos
5 years, 2 months ago

Agile SOA in the Digital Economy

Are you and your enterprise a prisoner of the past? I don’t mean legacy applications and technologies, I mean today’s business processes and applications. I work with many different enterprises and what’s common to the great majority is the centrality of business processes and applications, and the difficulty in evolving these existing solutions.

Actually I am frequently amazed at the understanding of many business managers. I marvel at how they use the lingua franca of their applications to describe their business. I will readily admit that when I first meet someone like this it’s a bit scary, because their vocabulary is like a foreign language. But frequently I find that it’s also a foreign language to their colleagues and it represents a rather primitive form of power play! Believe me. And that vocabulary of course often pervades the business process also. But the even scarier thing is that these organizations don’t realize they are locked into yesterday; or looking in the rear view mirror is you prefer. And just like Fred Brooks mythical beasts, struggling against the grip of the tar pits [1], they will eventually be overwhelmed by the complexity and their inability to change. Yes they may be delivering Cloud based Web and mobile applications to their customers, but are they just adding to the inherent business complexity?

I observe smart, successful companies making major mistakes as they enter the digital economy. First they set up an eServices project or division. This is treated as an innovation center and separated from the core business, in order to get to market quickly. But of course when they get to market the new products don’t integrate with the core business. Sure there’s application and service integration, anyone can patch old and new together at that level; but what about the way the business works; the business model and the vocabulary used, the opportunities for channel switching, and the development of distinctive sales and customer support systems and internal and external company culture that transcends the technology channels. And the ability to evolve the old and new in a way that they complement each other?

This problem is visible in the decreasing agility of organizations. Many have adopted Agile development but, and I say this as a certified Scrum Master, how many Agile projects think about the vocabulary and integrated business model issue? Yes Agile projects generally deliver faster, better and cheaper, but are they basically adding to the size and eventual grip of the tar pit? Just getting there faster!

In the digital economy enterprises must turn themselves inside-out! Expose their core business capabilities as services through multiple, interconnected channels for internal and external use. Today’s SOA best practice is primarily inwards looking. What’s required is a new form of business model that details the new world from the customers’ perspective. And this needs to be reflected in the way the business operates internally also.

The new business model needs to be a radical departure from de facto practices in business architecture, enterprise architecture or business requirements. And it needs to be developed to govern Agile development projects. Key characteristics include:
– A service oriented business model that transcends business and IT.
– Understandable by all stakeholders
– Owned by the business.
– All enterprise capabilities are (eventually) published as externalized business services and supported by common software services
– Implementation independent models
– Developed as part of an Agile process – initial scoping sprint, followed by drill down modeling sprints by domain and or capability; delivering just sufficient detail to charter Agile delivery projects.

[1] The Mythical Man-Month, Fred Brooks, 1972

5 years, 2 months ago

Agile SOA in the Digital Economy

Are you and your enterprise a prisoner of the past? I don’t mean legacy applications and technologies, I mean today’s business processes and applications. I work with many different enterprises and what’s common to the great majority is the centrality of business processes and applications, and the difficulty in evolving these existing solutions.

Actually I am frequently amazed at the understanding of many business managers. I marvel at how they use the lingua franca of their applications to describe their business. I will readily admit that when I first meet someone like this it’s a bit scary, because their vocabulary is like a foreign language. But frequently I find that it’s also a foreign language to their colleagues and it represents a rather primitive form of power play! Believe me. And that vocabulary of course often pervades the business process also. But the even scarier thing is that these organizations don’t realize they are locked into yesterday; or looking in the rear view mirror is you prefer. And just like Fred Brooks mythical beasts, struggling against the grip of the tar pits [1], they will eventually be overwhelmed by the complexity and their inability to change. Yes they may be delivering Cloud based Web and mobile applications to their customers, but are they just adding to the inherent business complexity?

I observe smart, successful companies making major mistakes as they enter the digital economy. First they set up an eServices project or division. This is treated as an innovation center and separated from the core business, in order to get to market quickly. But of course when they get to market the new products don’t integrate with the core business. Sure there’s application and service integration, anyone can patch old and new together at that level; but what about the way the business works; the business model and the vocabulary used, the opportunities for channel switching, and the development of distinctive sales and customer support systems and internal and external company culture that transcends the technology channels. And the ability to evolve the old and new in a way that they complement each other?

This problem is visible in the decreasing agility of organizations. Many have adopted Agile development but, and I say this as a certified Scrum Master, how many Agile projects think about the vocabulary and integrated business model issue? Yes Agile projects generally deliver faster, better and cheaper, but are they basically adding to the size and eventual grip of the tar pit? Just getting there faster!

In the digital economy enterprises must turn themselves inside-out! Expose their core business capabilities as services through multiple, interconnected channels for internal and external use. Today’s SOA best practice is primarily inwards looking. What’s required is a new form of business model that details the new world from the customers’ perspective. And this needs to be reflected in the way the business operates internally also.

The new business model needs to be a radical departure from de facto practices in business architecture, enterprise architecture or business requirements. And it needs to be developed to govern Agile development projects. Key characteristics include:
– A service oriented business model that transcends business and IT.
– Understandable by all stakeholders
– Owned by the business.
– All enterprise capabilities are (eventually) published as externalized business services and supported by common software services
– Implementation independent models
– Developed as part of an Agile process – initial scoping sprint, followed by drill down modeling sprints by domain and or capability; delivering just sufficient detail to charter Agile delivery projects.

[1] The Mythical Man-Month, Fred Brooks, 1972

5 years, 5 months ago

Agile Business Modeling – The Core Heuristic?

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.
5 years, 5 months ago

Agile Business Modeling – The Core Heuristic?

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.