Search Results for: business model

Enterprise Modernization – The Next Big Thing!

by

“We tend to think the strong will survive, but a virus is a very small thing that kills big things.” Horace Dediu, Clayton Christensen Institute, speaking about the fall of Nokia.

All enterprises, be they large or small, national or multinational, commercial or government agency, American or Chinese, Japanese or European, are carrying the dead weight of their history and almost certainly continuing to add unnecessary complexity and excessive cost that will progressively reduce effectiveness, with the potential to trigger existential crises. Newer enterprises including Internet platform and Cloud based companies are not immune from this effect. As Horace Dediu has commented, Nokia is a classic case of a large enterprise brought from market leadership to irrelevance and zero value in an extremely short space of time.

In the past, modernization has become synonymous with technically related “application modernization” The term “modernization” is commonly used to refer to information systems, applications and technologies. And it is very common for systems or applications to be “modernized” because a technology has come to the end of its life, or an application is so antiquated that it cannot support newer business process patterns such as multi-channel and mobile. More generally organizations clearly implement modernizing programs without necessarily using the modernizing name. For example transformation programs or projects will often involve considerable elements of modernization. Similarly adoption of Agile methods may be considered a form of process modernization. Or the introduction of DevOps practices, enterprise architecture, master data management, life cycle management etc. But it is notable that each of these forms of modernization are discipline centric. It is very rare for an enterprise to undertake concerted effort to understand what modernization really means for a specific enterprise and to plan and execute modernization that delivers inter-discipline collaboration in support of specific modernization objectives and goals.

Each enterprise has unique modernization needs. A bank may see a primary modernization goal to establish core banking systems that reduce the risk of negative customer impact, such as delays or errors in transaction processing. Also to be able to introduce price and product change in days or weeks. A healthcare company may similarly see the requirement to change prices rapidly but equally the need to rapidly implement new legislation. A retail enterprise may see the ability to interact with customers using processes that span multiple technology, shopping and delivery channels, and to be able to influence the customer decision making process to achieve maximum customer satisfaction.  A key element apparent in all these modernizing goals is that modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change, targeted at the very specific areas that are mission critical for the individual enterprise.

The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.

What’s required is a modernization approach and strategy that progressively breaks out business and technology components that establish highly independent units of business capability that comply with a reference model and architecture that ensures architecture agility and implements clear fire breaks between the components.

But as discussed, enterprises are extremely reluctant to undertake modernization as they see it as all cost and risk. Transformation projects are widely viewed in the same way. And anyway immediate business priorities always trump housekeeping!

There are various aspects to a successful modernization approach. But the most important are:
1. Define Agility Vectors. Identify the top priorities for business agility and integrate relevant actions into all business projects. Here are some examples:
a. Radical improvement (time and cost) in response to legislative change
b. Generalization of existing capabilities to support new products and services
c. Dramatic reduction in new product time to market
d. Integration of existing capabilities to leverage disparate channels
e. Separation of common and customer/channel specific capabilities
I refer to these as “vectors”. Mission critical goals that will require actions and change right across the organization. Single projects are generally not going to cut it. Therefore the vectors provide a mechanism to exert influence (demand shaping) over the incoming application demand management pipeline and to select and coordinate multiple project actions.
2. Mandate Reference Architecture for Agility. Establish a reference architecture for business agility that defines the minimum necessary architecture compliance to ensure continuous business evolution. Mandate that all core business capabilities are implemented as software services and components.
3. Integrate Agile Architecture AND methods. Implement Agile practices that give equal weight to agile architecture and agile project delivery. Demonstrate small, incremental delivery steps, business capability by capability, service by service.
4. Govern business agility. Automate governance by establishing model driven architecture and development tooling that ensures compliance with the reference architecture.
5. Integrate Business and IT. Practice conceptual business modelling to establish common business and IT vocabulary independent of existing applications, align business and software services and reengineer the organization around business capabilities and services.
6. Get top level sponsorship for the Enterprise Modernization Roadmap. Recognize enterprise modernization as a major business priority and elevate to the highest levels of the enterprise to make it happen.

The enormous, disruptive creativity of Silicon Valley is transforming how companies make decisions, store data, reach potential customers, outsource activities, processes and capabilities, and how people communicate, make friends, protest and shop. No enterprise is immune from this effect.

Accordingly, modernization today means reinventing the way enterprises work, the business model and systems, and being genuinely agile. You only do this by ripping up today’s world and turning it into a genuinely flexible structure of independent components that can flex and morph continuously.

Application Modernization should be long dead and buried. Enterprise Modernization is an existential priority for all enterprises, not just those with mainframes and COBOL!

Note 1: Understanding Agile Adoption Failure

Enterprise Modernization – The Next Big Thing!

by

“We tend to think the strong will survive, but a virus is a very small thing that kills big things.” Horace Dediu, Clayton Christensen Institute, speaking about the fall of Nokia.

All enterprises, be they large or small, national or multinational, commercial or government agency, American or Chinese, Japanese or European, are carrying the dead weight of their history and almost certainly continuing to add unnecessary complexity and excessive cost that will progressively reduce effectiveness, with the potential to trigger existential crises. Newer enterprises including Internet platform and Cloud based companies are not immune from this effect. As Horace Dediu has commented, Nokia is a classic case of a large enterprise brought from market leadership to irrelevance and zero value in an extremely short space of time.

In the past, modernization has become synonymous with technically related “application modernization” The term “modernization” is commonly used to refer to information systems, applications and technologies. And it is very common for systems or applications to be “modernized” because a technology has come to the end of its life, or an application is so antiquated that it cannot support newer business process patterns such as multi-channel and mobile. More generally organizations clearly implement modernizing programs without necessarily using the modernizing name. For example transformation programs or projects will often involve considerable elements of modernization. Similarly adoption of Agile methods may be considered a form of process modernization. Or the introduction of DevOps practices, enterprise architecture, master data management, life cycle management etc. But it is notable that each of these forms of modernization are discipline centric. It is very rare for an enterprise to undertake concerted effort to understand what modernization really means for a specific enterprise and to plan and execute modernization that delivers inter-discipline collaboration in support of specific modernization objectives and goals.

Each enterprise has unique modernization needs. A bank may see a primary modernization goal to establish core banking systems that reduce the risk of negative customer impact, such as delays or errors in transaction processing. Also to be able to introduce price and product change in days or weeks. A healthcare company may similarly see the requirement to change prices rapidly but equally the need to rapidly implement new legislation. A retail enterprise may see the ability to interact with customers using processes that span multiple technology, shopping and delivery channels, and to be able to influence the customer decision making process to achieve maximum customer satisfaction.  A key element apparent in all these modernizing goals is that modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change, targeted at the very specific areas that are mission critical for the individual enterprise.

The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.

What’s required is a modernization approach and strategy that progressively breaks out business and technology components that establish highly independent units of business capability that comply with a reference model and architecture that ensures architecture agility and implements clear fire breaks between the components.

But as discussed, enterprises are extremely reluctant to undertake modernization as they see it as all cost and risk. Transformation projects are widely viewed in the same way. And anyway immediate business priorities always trump housekeeping!

There are various aspects to a successful modernization approach. But the most important are:
1. Define Agility Vectors. Identify the top priorities for business agility and integrate relevant actions into all business projects. Here are some examples:
a. Radical improvement (time and cost) in response to legislative change
b. Generalization of existing capabilities to support new products and services
c. Dramatic reduction in new product time to market
d. Integration of existing capabilities to leverage disparate channels
e. Separation of common and customer/channel specific capabilities
I refer to these as “vectors”. Mission critical goals that will require actions and change right across the organization. Single projects are generally not going to cut it. Therefore the vectors provide a mechanism to exert influence (demand shaping) over the incoming application demand management pipeline and to select and coordinate multiple project actions.
2. Mandate Reference Architecture for Agility. Establish a reference architecture for business agility that defines the minimum necessary architecture compliance to ensure continuous business evolution. Mandate that all core business capabilities are implemented as software services and components.
3. Integrate Agile Architecture AND methods. Implement Agile practices that give equal weight to agile architecture and agile project delivery. Demonstrate small, incremental delivery steps, business capability by capability, service by service.
4. Govern business agility. Automate governance by establishing model driven architecture and development tooling that ensures compliance with the reference architecture.
5. Integrate Business and IT. Practice conceptual business modelling to establish common business and IT vocabulary independent of existing applications, align business and software services and reengineer the organization around business capabilities and services.
6. Get top level sponsorship for the Enterprise Modernization Roadmap. Recognize enterprise modernization as a major business priority and elevate to the highest levels of the enterprise to make it happen.

The enormous, disruptive creativity of Silicon Valley is transforming how companies make decisions, store data, reach potential customers, outsource activities, processes and capabilities, and how people communicate, make friends, protest and shop. No enterprise is immune from this effect.

Accordingly, modernization today means reinventing the way enterprises work, the business model and systems, and being genuinely agile. You only do this by ripping up today’s world and turning it into a genuinely flexible structure of independent components that can flex and morph continuously.

Application Modernization should be long dead and buried. Enterprise Modernization is an existential priority for all enterprises, not just those with mainframes and COBOL!

Note 1: Understanding Agile Adoption Failure

What’s Your EA End Game? Tales From TWC 2015

by

bg outline

By: Dave Hood, CEO, Troux

end game v2 042915 blogA couple weeks ago we held our annual Troux Worldwide Conference, inviting customers and partners from across the country and even the world to meet us in our hometown of Austin, TX. We hosted customers from healthcare to banking, from public sector to consumer packaged goods. Aside from the compelling conversation, fantastic food and inspiring keynotes from the likes of TED alum David McCandless, it never ceases to amaze me what our customers are able to achieve through enterprise intelligence and EA toolsets. That’s the spirit of the conference – to help customers learn from the innovative approaches of their peers and to get the synapses firing on how they can transform their businesses through EI.

Basic transparency into a company’s IT operations, resources and processes is a victory, albeit one that should really be a given. It’s when more direct business value or tangible results can be derived from enterprise intelligence that EA becomes especially formidable and invigorating. You do need to have a clear goal of what you want to get out of an EA program, but the possibilities are figuratively endless.

Is your implementation a straightforward costing-cutting effort or an exercise to simplify your business model? Is it linked to business capability planning? Does it have to do with any of the extensive subset of application portfolio management outcomes, which include the creation of shared services, analyzing which apps are prime for cloud migration, shoring up cybersecurity through asset management, or reconciling shadow IT and standards? The list of possible outcomes goes on, but business leaders need to be able to see demonstrable results and understand exactly what they’re getting out of enterprise intelligence. Quite a few of the customers that presented at TWC have figured out how to tell their EA story in a way that resonates.

Consider Wells Fargo’s Consumer Lending Group, which has begun its EA journey by thinking big and having the courage to change, while starting small in an endeavor to bring shadow IT back under the appropriate umbrella. To date, they’ve been able to streamline, eliminate redundancies, consolidate and cut costs associated with over 250 standardized business functions, more than 2200 business processes and about one-fifth of 5000 existing apps. That’s a heck of a lot more value than just basic IT transparency.

Or take Devon Energy Corporation. Using EI, the company smoothly integrated 27 corporate acquisitions and was able to enforce data stewardship, going from just 1 percent of data being complete to 85 percent complete in only two months. In a sector that’s changing as rapidly as oil and gas, where prices and market factors soar and dive at the drop of a hat, it thrills us to know that enterprise intelligence can help Devon evaluate next steps for the business every single day.

Or how about Moffitt Cancer Center, where a core team of architects leveraged enterprise intelligence to evaluate a migration of key applications to the public cloud. Some of those apps and processes audit personal health info in a matter of hours rather than days or weeks, preventing black market insurance fraud. Talk about being critical and needing to know that they will absolutely work.

And last but certainly not least, our Troux Innovation Award winner: The U.S. Department of Energy, represented by Chief Enterprise Architect Rick Lauderdale. As another TWC guest Jason Bloomberg outlined, “[Lauderdale] helped the DOE transform the way they dealt with the risks inherent in obsolete software…Connecting the dots between IT asset management, cybersecurity, enterprise architecture, and the operationalization of IT information is a tall order, but is an increasingly familiar enabler of business agility.” Lauderdale not only revamped an application portfolio and increased cybersecurity, but he helped the DoE cut costs and is actively working on transferring the model to more than 10 other federal government agencies. Again, that’s serious impact.

Trust me when I say that these are just a few of the brilliant examples shared at TWC. You’ll see more on all of these customer programs over the rest of this year as their strategies and execution unfold. In some cases they’re just getting started on producing real change for the business, but they all prove one critical point. In order to see true value from enterprise intelligence, start by asking yourself, “What’s my EA end game?”



New Call-to-action

The Digital Race, Enterprise Edition

by

bg outline

By Dave Hood, CEO, Troux

race to digitize 030815 blogIn today’s global, hyper-competitive economy, you’re seeing all kinds of heated races to be the first to digitize an industry. You’ve got Uber battling Lyft to digitize (and displace) the traditional taxi industry. Apple, Google, PayPal, Square and others are slugging it out in a race to digitize the majority of retail transactions. Even seemingly mundane industries like shipping and storage – with Austin tech comrades uShip and SpareFoot racing incumbent competitors – heat up when digitization starts making things more efficient and accessible. And this makes the stakes quite high in the IT world, as enterprises leverage IT as they engage in a similar race to innovate digitally.

Call it what you will – digital transformation, digital revolution, digitization – but the C-suite recognizes a game-changing market disruption is underway. It’s a disruption that requires them to revamp their business model and determine how to deliver a sustainable competitive advantage. At its core, it’s a strategic imperative that C-suite decision makers of all types have to take seriously. According to a recent Gartner report titled “Digital Business Requires CIOs, CEOs and Strategy Officers to Improve Technology-Related Competitor Intelligence,” digital business is now competitive turf that differentiates between companies’ health, efficiency and product sets. We wholeheartedly concur with that.

The Gartner report encourages business leaders to look at their competitive landscape and evaluate where they stack up (no pun intended) in IT infrastructure, processes and advancement when it comes to emerging areas like the cloud, BYOD, data analysis and cybersecurity. The role of the CIO in this process and analysis is also made crystal clear:

“Discuss the traditional competitor landscape, so you know and agree where its natural boundaries lie. Then frame a new view of competition to include startups, entrants from adjacent industries and attack from the tech sector itself…If there is corporate myopia, the CIO must be an agitator, ensuring that the analysis of competition extends beyond traditional competitors and industries.” 

That’s a pretty weighty role for the CIO to play; they’re continuing to be relied upon as a business leader, not just an advisor or even worse an IT “utility provider.” And while we know that CIOs and their teams of IT decision makers are eager to innovate for the business and meet competitive challenges head-on, there may be a step missing here. How does a CIO (and their traditional business strategist counterpart) decide how the company compares to the competition if they don’t holistically understand where gaps exist in their own journey toward becoming a digital business? What areas need investment and how can they prioritize the changes that need to be executed? In other words, how can you compare your house to others’ when you don’t have yours cleaned up and in order or don’t even completely know what the blueprint looks like? To nail down improvements to the digital business and lead or follow fast in the industry, CIOs need to employ enterprise intelligence (EI).

Enterprise intelligence is complete, fast, prescriptive and (perhaps most importantly) real-time, all of which are key characteristics for CIOs as they use EI to do their benchmarking and strategic planning. Joe McKendrick recently covered the broader EA discipline for ZDNet, and a quote from McKinsey’s Oliver Bossert, Chris Ip and Jürgen Laartz does a good job of setting up the pressures related to digital business that enterprise intelligence can help alleviate:

“While most companies would have been comfortable in the past going through a three- to five-year transformation and not implementing new features in the meantime, today’s highly competitive markets no longer allow players to alter architecture and business models sequentially. It is therefore important to realize that the transformation toward digital is a continuous process of delivering new functionality.” 

The McKinsey trio also does a standout job of breaking down “two-speed IT architecture,” which addresses the two prongs of customer-centric front-end IT (apps, UIs, etc.) and the legacy systems IT back-end (compute resources, storage, etc.), both integral competitive fronts in digital business. Fortunately, enterprise intelligence can help CIOs, CEOs, COOs, CFOs and other strategy officers understand where they stand from both angles, appropriately relate their progress to that of the competition, and ultimately break the tape in the race to digital prowess and a better, sustainable competitive advantage.

Download the complimentary Gartner report here and check out our whitepaper, The Power of Enterprise Intelligence, to learn more about how our solutions help decision-makers take a step back to see the big picture to understand exactly where they should be investing in their business and where they should not.

 



New Call-to-action

Categories Uncategorized

The Annual Digitalization Reunion

by

QualiWare Center of Excellence has Booth 1 at the annual Danish Government Digitalization Conference (#offdig) in Aarhus on 24-25 March. Rune Brodersen and John Gøtze will be available at the booth both days, so feel free to drop by for a chat. Or for a demo of some of our new offerings: Archimate OIOEA Capability models Business Model […]

Using Big Data to Build a Strategy Toolbox

by

There is academic debate regarding whether big data helps or hurts strategy. In our research at MIT CISR, we’ve identified some important advantages to viewing big data as a strategic opportunity. In particular, companies can use big data to greatly improve and innovate their business model—and to extend their strategy toolboxes. Improving the Business Model […]

Your Digital Source of Competitive Advantage: Where to Start?

by

When it comes to optimizing digital business models, there are three sources of competitive advantage: content, customer experience, and platform. However, very few businesses excel in all three areas. Just think about Trip Advisor. Is it known for amazing customer experience or a stellar platform? Neither—it’s largely known for its content. What about USAA? It’s […]

How Can You Win in the Digital Economy?

by

As more business becomes digital, customers are expecting the ability to interact with companies anywhere and anytime. A recent survey showed that 72% of customers would replace some traditional channels with mobile apps if given the opportunity. This means that companies need to get serious about their digital business models if they are going to […]

Real-Time Strategy is a Reality

by

bg outline

By Ben Geller, VP Marketing, Troux

speed of change 082214 2I was taken by surprise the other day when I looked at my calendar and saw that we are well into August; and before you know it summer will be over and autumn will be upon us. Immediately I started thinking about the ritual year-end strategic planning session that generally looms around now. I’m sure many of you know of what I speak.

Historically strategic planning has centered around regular sessions that evaluate business performance and goals over established periods of time. Some organizations even remain attached to the yearly planning cycle. But, with the introduction of digital business and disruptive business models, has this approach become broken, merely sending businesses into a pro-longed process of planning and budget allocating that is outdated before its executed?

I think it probably has, which means we have to start thinking about how to change our planning processes. Earlier this year we started dialogue on the very idea of how change is changing and how it affects the planning process. Our post, Beyond Technology: How Enterprise Intelligence Supports Business Strategy and Change, looked at how enterprise intelligence (EI) makes it possible for the C-suite to make necessary strategic business decisions at the drop of a hat:

The insights produced by EI tools allow Chief Strategy Officers to quickly and methodically maneuver the business as the market changes by delivering enterprise transparency that shows the cost, impact and benefits of change across the connected enterprise.

But, how does it work?

Good question. Let’s start by looking at real-time strategy. In this context ‘real-time’ means you get an immediate view of any given part of a business. The idea behind enterprise intelligence is to provide executives with a real-time, continuous strategic planning view that enables an assessment of the entire connected enterprise. Forbes talked about this recently in the article, Is Enterprise Architecture Completely Broken?:

Those EAs who truly embrace change – who work directly with business stakeholders to move their organizations to an increasingly agile state of continuous business transformation – will more likely find themselves adding real value to their enterprises. 

Using enterprise intelligence to immediately understand how a specific strategy will impact all the various parts of the business means informed decisions can be made efficiently in order to mitigate risk or capitalize on an opportunity.

Is that really possible?

At Troux, we help our clients do this everyday. As a result, the planning cycle is real-time and actionable.

The Troux mind map has become a popular tool that helps companies understand the types of outcomes they can achieve with real-time strategic planning. These outcomes generally come from finding answers to key questions, such as:

  • Where are business and IT out alignment?
  • Where is the business at-risk?
  • What are the impacts of change?
  • What are our future-state alternatives?

The mind map visually illustrates the answers to the questions that drive the desired business outcomes. These answers communicate strategy and impacts to the enterprise regardless of technical prowess or business acumen, putting stakeholders on the same page on how everything works together.

The more things change…

I do enjoy that annual opportunity to check-in with my peers and superiors for a state-of-the-union assessment, but I’m not sure it needs to be categorized as “the one” strategic planning session anymore. The world of EI allows us to understand our market position every day and make decisions and changes accordingly. Since we have the data and information at our fingers tips real-time strategy is a reality.  We can transform our annual planning sessions a daily dialogue that ensures we taking advantage of changes in the market. How long have businesses lamented that there is never enough time for strategic planning? Well, I think EI has helped us find it.



New Call-to-action

Categories Uncategorized

When does EA start to care about sociocultural influences?

by

Organizations do not work, in real life, like they work on paper.  On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information.  On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.

In real life, there are human beings and the tools that they use.  Sometimes the tools move information from one person to another.  Sometimes, they just aid in communication.  People meet and get to know other people, and they learn to trust some, and distrust others.  Some folks have different measures and motivations and just “pass by” one another.  Some subset of these people will have shared cultural values and expectations.  There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization.  Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently. 

Reality is a lot messier than pretty rectangles. 

Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change.  We are unique in that most other “change artists” are not focused on engineering and some even ignore science.  (see Daniel Pink’s TED Talk on the Surprising Science of Motivation).  Few even know how to spell aesthetics.  Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science.  Engineering is a mindset as much as a class of methods.  It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things.  Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.

As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise.  We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter. 

That is just lazy.

It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures.  We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do. 

The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at.  Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.

We should consider sociocultural information if:

  1. Sociocultural influencers can impact the speed of change in an organization.
  2. Sociocultural connections can impact the decision making and governance processes
  3. Sociocultural strengths would allow rapid improvement in business capabilities needed for a shift in strategy
  4. Sociocultural blind spots would prevent an organization from recognizing an existential threat

 

Think about it.  Do you believe that any of those statements are false?  I can find ample examples for each one.  So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?

It’s only hard because we haven’t tried.

(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).

Agile and the Fairy Godmother

by

Once upon a time, a long, long time ago, well some 20 years actually, some clever folk figured out a way of structuring work that was quite revolutionary. So revolutionary in fact that most people didn’t understand it. Now a few folk in a parallel world worked hard over the years to make this method work, and they invented more ideas, frameworks and tools. And every day they are constantly improving their productivity and quality; and many of them also use Agile methods, as they are entirely complementary to the revolutionary method. The method – Design by Contract.

However the mainstream of the market seems to be fixated on Agile methods, as being the metaphorical silver bullet. Yet we all can’t help noticing that Agile Land is not such a happy place. There is continuing debate about the difficulties of making the methods work in the enterprise; the fragmentation of the original Agile principles and the outbreak of religious wars. And I am minded to comment, again, that the root problem with Agile methods is that they are one-dimensional – solely focused on people and process to the exclusion of all the other opportunities to create agile businesses.

At the heart of the conundrum is the need to focus on some different questions. Such as:
– How can we reduce the amount of work that has to be done?
– How can we structure the outcomes (deliverables) so they are inherently agile?
– How can we structure the work so that there is real traceability between the intrinsic business model and the delivered systems and services?
– How can we ensure that overall technical debt is always reducing faster than new functionality is being delivered?
– . . .
You get the idea.

So back to my parallel world. In Design by Contract the business problem, typically the Use Case, Services and Operations are attributed with Pre-conditions, Post-conditions and Invariants (rules that must remain constant). These artifacts provide us with functional and design level specifications that can be produced in an Agile, iterative manner, that
a) Deliver implementation independent service specifications (descriptions if you prefer)
b) And therefore also for publishing API specifications
c) Form the basis for structuring the code that is fully traceable to the business model
d) Create inherently agile systems and service structures
e) Create the structure (stubs) for Unit, Integration, Functional and Regression testing
(e.g all conditions and rules within a given test scope must be tested)
f) Depending on the technology employed to define the conditions and invariants, (rules engines, pseudo languages etc) both code and test cases can be produced automatically.

I was prompted to write this blog because I happened to read Rob Marvin’s useful blog on testing, and his very interesting ideas for improving test productivity to keep up with Agile projects. In his piece he talks about automation, but actually seems to miss the opportunity to auto-generate the test cases. Even more important, he seems to believe that the current state of Agile projects is his benchmark that he has to keep up with. I would comment that state of the art Design by Contract projects together with model driven frameworks are delivering order of magnitude greater productivity with exceptional quality, and this ought to be the where testers should set the bar.

Sometimes it seems to me that the Agile methods community is rather in the situation of hoping a Fairy Godmother will appear, wave a magic wand and all will be well. Everyone will use Scrum like they ought to; enterprises will waive their awkward little requirements for inter-project coordination and all will be well. But while the Agile community continue to ignore the broader scope of agile enablers this day won’t come.

If you are interested in an example of Design by Contract at work take a look at the Agile Service Factory.

Agile and the Fairy Godmother

by

Once upon a time, a long, long time ago, well some 20 years actually, some clever folk figured out a way of structuring work that was quite revolutionary. So revolutionary in fact that most people didn’t understand it. Now a few folk in a parallel world worked hard over the years to make this method work, and they invented more ideas, frameworks and tools. And every day they are constantly improving their productivity and quality; and many of them also use Agile methods, as they are entirely complementary to the revolutionary method. The method – Design by Contract.

However the mainstream of the market seems to be fixated on Agile methods, as being the metaphorical silver bullet. Yet we all can’t help noticing that Agile Land is not such a happy place. There is continuing debate about the difficulties of making the methods work in the enterprise; the fragmentation of the original Agile principles and the outbreak of religious wars. And I am minded to comment, again, that the root problem with Agile methods is that they are one-dimensional – solely focused on people and process to the exclusion of all the other opportunities to create agile businesses.

At the heart of the conundrum is the need to focus on some different questions. Such as:
– How can we reduce the amount of work that has to be done?
– How can we structure the outcomes (deliverables) so they are inherently agile?
– How can we structure the work so that there is real traceability between the intrinsic business model and the delivered systems and services?
– How can we ensure that overall technical debt is always reducing faster than new functionality is being delivered?
– . . .
You get the idea.

So back to my parallel world. In Design by Contract the business problem, typically the Use Case, Services and Operations are attributed with Pre-conditions, Post-conditions and Invariants (rules that must remain constant). These artifacts provide us with functional and design level specifications that can be produced in an Agile, iterative manner, that
a) Deliver implementation independent service specifications (descriptions if you prefer)
b) And therefore also for publishing API specifications
c) Form the basis for structuring the code that is fully traceable to the business model
d) Create inherently agile systems and service structures
e) Create the structure (stubs) for Unit, Integration, Functional and Regression testing
(e.g all conditions and rules within a given test scope must be tested)
f) Depending on the technology employed to define the conditions and invariants, (rules engines, pseudo languages etc) both code and test cases can be produced automatically.

I was prompted to write this blog because I happened to read Rob Marvin’s useful blog on testing, and his very interesting ideas for improving test productivity to keep up with Agile projects. In his piece he talks about automation, but actually seems to miss the opportunity to auto-generate the test cases. Even more important, he seems to believe that the current state of Agile projects is his benchmark that he has to keep up with. I would comment that state of the art Design by Contract projects together with model driven frameworks are delivering order of magnitude greater productivity with exceptional quality, and this ought to be the where testers should set the bar.

Sometimes it seems to me that the Agile methods community is rather in the situation of hoping a Fairy Godmother will appear, wave a magic wand and all will be well. Everyone will use Scrum like they ought to; enterprises will waive their awkward little requirements for inter-project coordination and all will be well. But while the Agile community continue to ignore the broader scope of agile enablers this day won’t come.

If you are interested in an example of Design by Contract at work take a look at the Agile Service Factory.