business agility

6 years, 11 months ago

Architect Process Agility With BPM Platforms For Digital Business

by

Some CIOs and enterprise architecture (EA) pros believe that business process management (BPM) is on the opposite side of agility — but they don’t realize that BPM technology itself is also evolving. Agility-oriented BPM platforms are the foundation o…

9 years, 11 months ago

Agile Business Modeling – The Core Heuristic?

by

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.
9 years, 11 months ago

Agile Business Modeling – The Core Heuristic?

by

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.
10 years, 6 months ago

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

10 years, 6 months ago

The Agile Enterprise Value Chain

by

Agile methods have not been widely adopted by enterprises. Agile projects remain, for the most part, independent software development activities, and often by design focused on key areas of enterprise innovation. The latter makes sense, but we should question why Agile concepts should not be rolled out more broadly, because there are considerable opportunities for process improvement across wider range of project classes as well as greater coverage of the end to end life cycle.

If we take this broader, multidimensional view, it should also help enterprises to take a more mature position on agile and agility. Agile methods are primarily guiding management and to an extent project management practices. The business value focus is therefore not surprisingly on “project” quality, cycle time and cost. If we take a broader view we can also focus on enterprise level business improvement, governance and end to end process optimization.

Nobody wants to overload an Agile delivery process unnecessarily. But there are key enterprise perspectives that need to be addressed, and good way to figure out which contribute to the overall delivered agility is to model business value. The business value model allows us to a) develop and refine the solution delivery value chain required for varying enterprise and project contexts and b) charter (structure, manage, govern) architecture and delivery projects with greater probability of achieving optimal outcomes. 

Naturally all enterprises and projects have varying needs for business value. Yes, fastest cycle time and lowest cost are always important, but we can imagine that these will be reasonably compromised for the right business improvement, or reduced risk. A good place to start therefore is by considering the agility related business value required for a project, scenario or enterprise in its broadest sense and relate this to delivery life cycle outcomes. In the simple model below I have listed some practice domains and potential outcomes and then mapped these to candidate business benefits.
Agile Outcomes Mapped to Business Value (Example Fragment)
I have focused Agile practices on Lean process values because these seem to encapsulate all the various Agile methods. In addition I have included disciplines that focus on typical enterprise activities including architecture, asset management, application lifecycle management and automation. I don’t pretend this list is exhaustive, it’s merely illustrative. I am sure readers will have many ideas for practice domains and relevant outcomes. I then mapped this starter list against business benefits using the very effective approach that I cribbed from COBIT5 when I was developing extensions of same. FYI P: Primary, S: Secondary.

This analysis then provides structured data on which to develop an agility value chain (diagram below). I’m sure readers will be very familiar with this technique, first described by Michael Porter[1].  For further explanation see my introduction in Realizing the Agile Enterprise.
Agile Enterprise Value Chain
There are some key points to make about the agile value chain:
1. The primary activities are a cohesive set of activities, and it is important to optimize value across the entire life cycle. For example:
– Addressing software development alone is likely to be suboptimal.
– Making sure that demand is understood, grounded in business strategy, aggregated across lines of business and geographies where appropriate, decomposed into optimal units of work, consolidated into units of release and so on is key.
– Establishing clarity of purpose and matching with an optimal delivery approach.
– Integrating the activities of architecture, definition and delivery in a continuous value chain that minimizes architecture and definition efforts based on value creation. 

2. The value of primary activities can be dramatically enhanced with good supporting activity.

3. That supporting capabilities may be delivered using primary activities which either have qualified goals and objectives, or that the outcomes of primary activities are harvested to create supporting capabilities. For example, in the typical enterprise there are frequently considerable benefits to be gained from reusing many types of asset such as  services, components, schema,  platforms, patterns etc. but it is relatively unusual for enterprises to capitalize on these opportunities for a multitude of reasons including politics, budgets, ownership and support. However if the potential value can be demonstrated and quantified in terms of reduced delivery times and costs, then a business case can be made to put effective systems put in place. 

4. Agile concepts do not just relate to software development! There is great opportunity to adopt key Agile concepts including particularly Lean, Kanban and Scrum, across the entire delivery value chain, particularly for primary activities such as demand and define, and supporting activities such as governance, architecture and delivery infrastructure.

5. That few enterprises are independent, and collaborations are part of business as usual. Further, innovative forms of collaboration may be actively pursued relative to the enterprise’s goals, which might result in widespread use of a common platform, business or technology services, or involvement of unconventional partners such as brokers or social networks.

The Value Chain provides a framework for analyzing the relative business value of the capabilities involved in product delivery in terms of agility outcomes.  In the table below I have shown just a small fragment of what this might look like. I have decomposed each Value Chain Activity into capabilities and assessed potential agility outcomes. Some very obvious extensions would be to include scoring (weighted support to business level benefits) plus inter capability dependencies. A logical conclusion might be to quantify value in terms of cycle time hours or cost reduction, but this seems unnecessary for our purpose here.

Capabilities Mapped to
Agility Outcomes  (Example Fragment)
The detailed Value Chain provides a structured basis for creating and communicating delivery life cycle templates. And it occurs to me this could be just the way to address the elephant in the room for many enterprises – the SDLC standard, commonly a formally mandated standard that is all but ignored by most projects. For most enterprises I believe there are just three basic delivery patterns which provide three template choices, and I will expand on these shortly. I will also be discussing all of the value chain activities in some detail.
Talk to Everware-CBDIabout the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.

[1] Porter, M.E. (1985) Competitive Advantage, Free Press, New York, 1985.

10 years, 7 months ago

Realizing the Agile Enterprise

by

Have you noticed? Organizations have become initiative driven. Ten years ago enterprise architecture was topic de jour precisely because of initiative fatigue. But today there’s a huge focus again on narrow focus strategic projects and programs, because they are (perceived to be) the only way to deliver business change fast.

Architecture, especially enterprise architecture, has become yesterday’s issue – primarily, many would argue because it failed to deliver the promised business agility. Challenging for the same mindshare but at the other end of the spectrum are Agile software development methods that bring an almost religious zeal to rapid delivery by concentrating responsibility on self-managing, cross functional teams. Don’t get me wrong, narrow focus teams are highly effective in solving complex problems that are intrinsically narrow in scope. The problem is that many enterprises are inherently complex, and well executed architecture is the only way in which complex problems can be broken down and structured in order to establish appropriately independent units of work that can be addressed in an effective manner using Agile methods.

There have been several well intentioned attempts to evolve Agile methods to be effective in an enterprise context, to deal with the inevitable complexity that goes with very large scale operations that demand high levels of regulation, governance, scalability, standard services and business processes. But these efforts are unlikely to succeed because they approach the problem through the narrow lens of the Agile methods.

At the same time we should observe that use of UML based model driven methods and tooling has not become widespread, as was once anticipated. Agile methods provide no guidance on “how” to undertake tasks and Agile practitioners by my own observation commonly reject the rigor of formal methods and tools. This single action without question limits the scalability of Agile projects making continuous change and iteration an effort intensive and lower quality activity.

Many enterprises have voted with their feet and in their use of Agile methods have adopted a hybrid approach commonly referred to as Water-Scrum-Fall. In other words, architecture, planning and requirements are undertaken in the time honored fashion, and development is executed using Agile methods, typically Scrum. In truth, Water-Scrum-Fall should be designated an Anti-Pattern because it perpetuates the inefficiencies of early phases and renders the Agile development process sub-optimal because conventional levels of requirements errors and development and test driven rework persist.

What’s happened is that Agile methods have in the main been adopted in a relatively uncritical and immature manner. It’s very noticeable that proponents of Agile methods strongly advocate adherence to the core concepts and methods, citing the transformational nature of the approach and the inherent dangers of compromise. Yet there are examples of Agile being used effectively in large scale, but these are the exception, and have usually been achieved with either, exceptional levels of skilled resources, or more probably considerable customization of method, together with high levels of structure and tooling.

One must conclude that adoption of Agile methods remains at an early stage of maturity, and that like many new ideas in many domains, will be evolved by convergence with depending and dependent practices, which themselves must also evolve.

A practical way to manage this maturing process is with a value chain of the business change delivery cycle.
Whilst architecture and structured methods and tooling are important as discussed, it’s clear there’s a larger ecosystem that Agile methods must collaborate with. This collaboration cannot be approached in a casual manner, it needs to be specified in detailed processes, practices and deliverables with appropriate automation to bring high levels of discipline to the end to end delivery process. It’s time enterprises applied the same level of process change effort to the IT activity that it does to the broader business. In this business improvement process it’s also important to note that Agile concepts can be productively applied to a broader range of activity than purely software development. And as with any value chain, there’s great opportunity to organize the supporting activities and leverage common practices, methods, resources and assets.

The very pace of technology change means today’s enterprise is inevitably going to be initiative driven, but this doesn’t mean initiatives should be isolated in order to be successful – this is a path to delivering instant legacy. Rather Agile methods and concepts are effective Organizing and Management approaches, and they need to be integrated into the broader value chain, particularly architecture and life cycle automation, that delivers rapid business change. 

Talk to Everware-CBDI about the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.

11 years, 3 months ago

How Adaptive Case Management Builds Business Agility

by

Business agility is all about being prepared for and able to quickly adapt to change. There has been so much written about agility from gurus like Peter Drucker, industry analysts like Forrester and Gartner, and the large well-respected community of process improvement practitioners that it would seem there is nothing new left to be said. […]

Related posts:

  1. Human vs. Machine: How Adaptive Case Management Helps Insurance Firms Serve Customers Have you seen the movie Real Steel? In the storyline…
  2. The New iWorker Meets Adaptive Case Management IT organizations are faced with a growing set of user…
  3. Forrester Business Process Conference: How Dynamic Case Management Helps Businesses Hit High Velocity Improvements I just returned from this year’s Forrester Business Process Conference…

Related posts brought to you by Yet Another Related Posts Plugin.

11 years, 4 months ago

Understanding Agility the Hard Way!

by

Agility is one of those words beloved by software industry marketing people. Over time it has become almost embarrassing and meaningless. Yet if you are in doubt I suggest asking Eastman Kodak, RIM, Palm, Yahoo or Nortel what they think the term means. When you don’t have agility you understand it all too well.

In today’s FT John Gapper says: “Kodak’s experience has a lesson for companies in the grip of rapid technological change. As Kenny Rogers sang, “You’ve got to know when to hold ‘em, know when to fold ’em”. Unfortunately, most public companies are run by people who hate folding ’em, and instead keep returning to the shareholders and bondholders for more chips. . . . Few senior executives, when debating options for a technology company in decline, admit defeat and run it modestly. Instead, they cast around for businesses to buy, or try to hurdle the chasm with what they have got. Sometimes they succeed but often they don’t, wasting a lot of money along the way.”

It brings to mind Fred Brooks essay on software engineering. “No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the mind’s eye one sees dinosaurs, mammoths, and sabretoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks.”

When all is going well investing for agility may seem a luxury. Why make capabilities genuinely independent so they can be switched in or out, or truly generic so they can be used in many different contexts if there’s no obvious or short term ROI? By the time you can accurately compute the ROI it will probably be too late.

Ref: Fred Brooks: the mythical man-month, Addison Wesley, 1975