Search Results for “business model” – Page 171

busoto is collaboration

November 22, 2012 by Jeff Kennedy

In 2011, and again in 2012, while preparing to cofacilitate with Ric Phillips1 a workshop about collaboration across an enterprise-architecture community of practice, we were reminded with jarringly clarity that the word collaboration is misunderstood and misused, and that unhelpful behaviours result from this misunderstanding and misuse. Under the banner of collaboration are in fact […]

SOA for Profits

November 18, 2012 by Peter Sjølin

If you look for a great book on how to deal with the implementation and adaption of an Service-Oriented Architecture the book SOA for Profits is what you are looking for. The book was published back in 2007 but is still highly relevant. The focus is on handling the needed interaction with stakeholders to collaborate […]

Two Weeks with Microsoft’s Surface RT

November 15, 2012 by Debasish Mishra

There’s been a lot of buzz about Microsoft’s entry into the computing hardware market with the Surface tablets. I’ve been using a Surface Tablet RT (the version using the ARM processor) for the past two weeks and have gotten a … Continue reading →

The Planning Paradox

November 14, 2012 by Gabriel Morgan

One of my uncle’s favorite jokes goes like this:

Greg: “Hey Gabriel, say to me ‘what’s the most important thing about humor?’”

Gabriel: “Okay Greg, what’s the mo-“

Greg: “Timing.”

[At this point, you’re supposed to laugh]

“Timing” is the most important thing to business strategy planning

As it turns out, timing is also the most important thing to support business performance management in terms of managing scorecards and synchronizing them with their project portfolios across a company.

Organizational Hierarchy Strategy Alignment. Organizational Hierarchy Strategy Alignment is the linkage between organization’s scorecards and budgets based on an organization’s hierarchy. The head of an organization’s scorecard and budget links to its children’s organizational scorecards and budgets forming a pyramid-like structure of strategy alignment like the illustration below.

Value Stream Strategy Alignment. From a business strategy perspective, there are two types of organizations in a company; Business Organizations and Support Organizations. A Business Organization is an organization that is responsible for a product with scorecard KPIs related to market share, revenue and customer satisfaction.. All other organizations in a company are Support Organizations with scorecard KPIs related to cost, productivity, quality and risk. Business Strategy is set by the Business Organizations and Support Organizations mobilize to enable them, ideally in a sequential flow based on the Product’s value stream (aka core value stream, value chain and operating model). That is, organizations that deliver a product define their scorecards to express what success look like normally using KPIs like “units delivered”, “revenue received”, “customer satisfaction”. Then, working back up the value stream, Support Organizations determine how to sell the product to hit the desired success targets set by the deliver organization. Then, Support Organizations that market the product define KPIs on their scorecards to express what success looks like to hit the sale’s organization’s KPI Targets. Of course, not all processes are directly involved in the core value stream. Support Organizations that support customers, invoice/bill customers, hire people, manage partners, etc all have an enabling/support role and should work back from the core value stream process to determine what their success looks like based on the organization’s processes that they support. Here’s an illustration of a business strategy cascaded via value streams.

The Planning Paradox

More common than you think, organization’s use a planning schedule to arrive at organizational scorecards and budgets that starts at the top of an organizational hierarchy and flows down from there. The problem is that organizations are rarely organized by value streams. In situations where the Business Organization is a sibling organization to Support Organizations, they both have to produce their scorecards and budgets at the same time forcing Support Organizations to scramble to discover the Business Organization’s strategy to then set their own scorecard for success and the budget necessary to achieve it. Even further, there are times when Business Organization functions report to Support Organizations forcing the Support Organization scorecards and budgets to be set before the Business Organization can declare what they need to be successful. In my experience, this situation causes several intense activities in brief stints that ultimately result in a undocumented alignment of business strategy leaving open the possibility of gaps, overlaps and conflicts in plans to execute the business’ strategy.

To add to the problem, it’s also worth mentioning these challenges posed when business strategy is poorly aligned:

Lack of ability to perform impact analysis to make upstream groups aware of dependent projects slipping/failing to set expectations
60% of Organizations don’t map Organizational Scorecard KPIs to funded projects *
66% of HR and IT organizations have no link to the business strategy *
70% of middle manager’s and 90% front-line employee’s compensation not linked to the business’ strategy *
95% of employees in most organizations do not understand their business’ strategy *

* Harvard Business School, 2006, “The Office of Strategy Management”, http://hbswk.hbs.edu/item/5269.html

Agile Architecture

February 22, 2013November 14, 2012 by David Sprott

The English language is well known for its subtlety. Sometimes it’s a delight, but on other occasions it can be very frustrating. If I use the term Gothic Architecture you will immediately understand I am describing a style of architecture that flourished in medieval times. And if like me you are interested in ecclesiastical architecture you will know that this style was used in many of the great cathedrals and churches across Europe, which were distinctive because of key architectural patterns that enabled great increases in height and internal light of the buildings without increasing the size of supporting pillars.

Now if I use the term Agile Architecture, what am I referring to? In today’s Agile world I would hazard a guess that most readers will think I am referring to the architecture techniques and tasks undertaken in the context of an Agile software development project, not the collection of patterns and practices that enable agile business systems. That is, an architecture that enables agility.

This potential for miscommunication is a core issue for enterprises. There is ample evidence that Agile Architecture is a primary contributor to business agility, yet we do not have a well understood architecture management system that integrates with Agile methods.

Let’s use an example readers may be familiar with. Amazon CEO Jeff Bezos famously[1]issued an edict that laid down some key architecture principles to Amazon development teams that I will summarize as:

· All teams will henceforth expose their data and functionality through service interfaces.

· Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed.

· It doesn’t matter what technology they use.

· All service interfaces, without exception, must be designed from the ground up to be externalizable.

· No exceptions.

What Bezos did here was to lay down key business and technology architecture principles that you might reasonably conclude were central to the extraordinary level of business agility that we have seen demonstrated by Amazon.com, Inc. That widely circulated edict contained the foundations of the Amazon reference architecture.

In the October 2004 CBDI Journal[2] we commented, “Two of the most successful and enduring dotcom start-ups, Amazon and eBay, now expose their core applications as Web Services. In doing so they have created a new class of platform that could have a profound impact on end-user organizations and IT vendors alike.”

And so the reference architecture became the enabler of growth and agility for the Amazon business, not we understand[3] as a grand plan, but through natural technological evolution. The services formed the platform that allowed the extraordinary expansion of the Amazon business that I would be certain not even Jeff Bezos imagined, back then in 2004. That is real business agility, and it was delivered by smart architecture backed up by clear policies and realized by agile processes.

Although Amazon has clearly evolved in pursuit of solutions to specific business opportunities and challenges, it’s also clear they have established a de facto architecture and architecture management system that guides the work of the many product delivery teams and ensures consistency of approach where it’s required. Let’s consider how an enterprise might establish a similar agile architecture management system.

A reference architecture articulates primary principles that are typically central to an entire enterprise. Principles should be focused on establishing the product and solution independent environment in which agility can be delivered and maintained, so they would be stable over time. We might refer to reference architecture as a Level 1 architecture perspective (L1) that exists purely as a set of models and guidelines.

Larger enterprises should explore the business value potential of platform based architecture as a mechanism to deliver cross enterprise consistency of core reference architecture behaviors and to enable closer integration with the wider ecosystem including customers, suppliers, end consumers etc. This is an extended management services platform which encapsulates the technology infrastructure and enables rapid delivery of business services.

The platform architecture defines common services that manage business delivery including security, life cycle management, change management, release management and operations, as well as catalogs, eCommerce, B2B, regulatory control and risk management, standardizing these key capabilities and reducing the footprint of business domain services. The platform will also manage important behaviors that deliver on specific business goals such as scalability and availability. For example, Amazon services are usually very fine grained, specifically to reduce the scope of each service in order to facilitate narrow focus SLAs and maximize scalability by reducing individual service complexity. We might refer to platform architecture as a Level 2 architecture perspective, engineered to be relatively stable in support of large numbers of business services and consumers, but also engineered to evolve and respond rapidly to business and technology change. Not all enterprises will see business value in making their platform and business services available to their ecosystem, but some will.

Enterprises clearly vary considerably in their make up in terms of geographic and organizational, product and process standardization and differentiation, but typically there will be considerable potential for an inventory of shared assets that leverage agile architecture to support business agility. The assets may include:

· Common services, frameworks and components that are designed to deliver common behaviors to all parts of the enterprise. For example core services that establish genuinely enterprise wide services such as Customer, Ticket, eCommerce etc; services that deliver business value by standardizing common business services and processes.

· Configurable services, frameworks and components that are designed to provide common behaviors but are engineered to be customizable in local situations to accommodate many aspects of localization ranging from the simple – taxation, geography etc, to the complex – variant ordering patterns, variations in event and process sequence dictated by local de facto business practices. Configurable services may provide business value simply by providing reusable components, or they may establish a common core of business process and information that establishes common reporting and regulatory control in a local context, or both. Configurable services may also be an important time to market strategy for service providers who customize their services for each client or customer group.

· Information architecture and services. Establishing a coherent approach to information is commonly a major issue for large enterprises and this architecture level defines an integrated approach for structured and unstructured (big) data, transactional and reference, enterprise reporting and regulatory control and so on.

Common and Configurable assets together with the Information Architecture might form a Level 3 architecture perspective and be widely applicable across a large, distributed enterprise.

We then have two further levels which are closely related, Family Architecture and Product Line Architecture. Whilst many architects chose to view Family and Product Line as synonyms, I recommend that they are kept separate. A Family architecture is a domain framework that is much more specialized that L3 assets that would be applicable on a broader basis. The Family architecture establishes core business (domain) services and possibly other artifacts specific to the domain, where the domain is likely to be a subject area or a cluster of major types. For example Customer, Supply Chain, Manufacturing, Risk etc. Families are also commonly acquired products.

In contrast Product Line architecture is what it says – it’s the architecture for a product offering. The product is an offering that has direct relationship to end customer revenue and usually continuity of purpose over multiple releases. Although from a narrow technical perspective the Product and Family architectures might be similar, the way a product is managed must mirror the business product life cycle. Family architectures may therefore be engineered for stability, whereas, depending on the industry sector, product line architectures may be engineered for maximum agility and minimum response time.

Finally we have the Solution architecture level, the architecture specific to solution project delivery, where the focus is on feature architecture and integrating solution architecture with the Level 1 to 5 architecture perspectives. It’s important to note that where product line architecture is used, then this may subsume the Solution architecture.

These six architecture levels provide us with a nomenclature for agile architecture that will be central to managing agility into the delivered product/solution. The architecture perspective guides the structure of programs and projects and the incorporation of architecture and reuse goals into delivery charters. The architecture also provides traceability and governance over realization of core architecture principles.

The question of how Agile Architecture integrates with Agile delivery is likely to prove contentious because architecture introduces a form of direction that contradicts Agile concepts. Yet the lessons from Amazon are insightful. The most senior business management need to be fully engaged and actively leading the development of architectural direction. Further in large enterprises customer project demand needs to be managed and aligned with business strategy and architectural direction.

There’s no reason why these Demand and Definition processes shouldn’t adopt Agile concepts, notably cross functional teams, time boxes and backlogs. The outcomes should be excellent visibility and traceability of key strategies and policies that provide real clarity of purpose for projects, that will increase the probability of success. In a typical large enterprise use of existing (or well understood) organizational concepts, adjusted to use aspects of Agile methods as discussed, will meet less organizational resistance. For example:

1. Architecture Review Board (ARB) or equivalent, a cross functional team (senior representatives of business, product management, architecture and delivery), that provide direction and funding to all architecture development.

2. Design Authority (DA), also a cross functional team (domain specific expert level representatives of business, product management, architecture and delivery), that transform raw customer demand stream into project charters and manage the portfolio view. It is the DA that takes responsibility for aggregating and decomposing customer and strategic demand, chartering Common, Product Line and Family architecture, typically as integral elements of delivery projects, which can demonstrate business value.

3. Investigatory architecture projects – short duration projects that validate assumptions prior to chartering composite architecture/delivery projects. Sometimes carried out as part of a Definition Phase activity concurrent with outline requirements and knowledge discovery. Using patterns as a mechanism to increase consistency of architecture decisions and communicate them to delivery projects at sensible level of detail that is useful to delivery teams. Recommend includes delivery team members as appropriate.

Note this is a recursive model, and the process may executed at enterprise and program level.

You may ask where Enterprise Architecture is in this. The answer is that enterprise architecture is a role and responsibility that must coordinate and govern all levels of architecture. Enterprise Architects are most likely to be assigned to a specific architecture perspective level. The notion of, “one architecture to rule them all” really doesn’t exist.

Each enterprise should develop its own architecture management approach, and integrate this into an end to end architecture, delivery and governance process. The term Agile Architecture should be used to describe and deliver architecture that facilitates the agile business by compliance with reference, platform and other architectures that facilitate evolution, customization and plug and play. Faster cycle time and quality outcomes are then a function of both the reusable patterns and parts available for assembly and the Agile delivery process.

In medieval times the builders of the Gothic cathedrals didn’t start their designs from scratch. But equally they didn’t have finely detailed (ivory tower) plans – the technology didn’t exist to support that. Master builders moved from city to city bringing their proven architecture in their heads, often together with experienced craftsmen, to new projects. Craftsmen and master builders together tried out new designs and gradually evolved core patterns such as the flying buttress, which became standard components in cathedrals across Europe. Sometimes the great buildings fell down during construction and the builders had to adapt the architecture and try again. They were truly early adopters of Agile methods as they combined architecture and build in what clearly was from time to time an empirical delivery approach, but they also had their equivalent of a reference architecture and patterns that enabled systematic reuse of proven designs. Of course their delivery cycle time was a little longer than today’s Agile project!

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] Amazon and eBay Web Services, The New Enterprise Applications? By Lawrence Wilkes, CBDI Journal October 2004

[2] Inadvertently published by Steve Yegge, 2011, in a comparison of Google and Amazon practices. http://upalc.com/google-amazon.php

[3] Werner Vogels, 2006, SOA creates order out of chaos @ Amazon, Rich Seeley, Search SOA

The Planning Paradox

November 14, 2012 by Gabriel Morgan

One of my uncle’s favorite jokes goes like this: Greg: “Hey Gabriel, say to me ‘what’s the most important thing about humor?’” Gabriel: “Okay Greg, what’s the mo-“ Greg: “Timing.” [At this point, you’re supposed to laugh] “Timing” is the most important thing to business strategy planning As it turns out, timing is also the…

Voterball: The Data Disruption of Electoral Politics

November 9, 2012 by Debasish Mishra

If there’s a great story coming out of the recent presidential election, it’s how analytical, evidence-based methods are disrupting the conventional wisdom of political pundits and campaigns to deliver significantly more reliable forecasts and actionable insights. The most … Continue reading →

The Agile Enterprise Value Chain

November 7, 2012 by David Sprott

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.

Rethinking the DIKW hierarchy

November 7, 2012 by Tom Graves

What are the relationships between data, information, knowledge and wisdom? This is one of the classic challenges in the knowledge-management [KM] space. The usual way to describe those relationships is that it’s a stack, or a hierarchy, or a pyramid,…

The Story behind “Stories That Move Mountains”

November 5, 2012 by Nick Malik

There is a new book available that I’d like to let everyone know about. It is called “Stories That Move Mountains.” I wrote this book with two fantastic professionals Martin Sykes and Mark D. West. In this post, I’m going to talk about how this book came to be, and why I felt so strongly about it that I invested two years of my life in bringing it to market.

First off, if you are interested in buying the book, and we think you will be, you can click on the image of the cover to take you straight to our “buy the book” page on the book’s sister site, StoriesThatMoveMountains.com.

Edward Tufte and Me

My journey into “rich information” began, as it did many others, when I heard about a book called “Visual Explanations” written by Edward Tufte. It was 1997, and the dot-coms were booming. I had left Microsoft to stake a claim in the modern gold rush. I was working as a development manager in a quickly growing web development company in downtown Seattle called Fine.com International. (see note)

On my team was a talented young web developer named Brian Poel who told me about a seminar he attended hosted by Tufte. In the seminar, Tufte taught about creating visual designs that inform, not just impress. Brian showed me the materials and I ended up reading Tufte’s book myself (Another bit of evidence to support the old saying: a manager is only as good as the smart people that surround him).

Visual Explanations: Images and Quantities, Evidence and Narrative At fine.com, we used the techniques described by Tufte in every way we could. His guidance led to design ideas that fed into the Nasdaq.com web site, the Marriott hotels web site, and many more. I learned the power of structuring information in a way that makes it easy to consume, elegant to perceive, and compelling to read.

It would be many years before I needed these techniques myself. That didn’t really start until I became a management consultant. The year was 2001, and the dot-com that I co-founded after leaving fine, Acadio, had failed along with tens of thousands of other young start-ups. I had moved to a consulting company called Sierra Systems Group (headquartered out of Vancouver British Columbia) to make ends meet. For the most part, I focused on technology activities, but I had to ramp up my communication skills. So I started using some of the rich information techniques that I learned from Tufte in our marketing and sales materials. I cannot say that I was particularly good at it.

I Can’t Draw… Seriously

I really can’t. Not even stick figures. Which is odd, because both of my parents, my eldest brother, and my daughter, are all gifted artists. Not that I can’t create useful diagrams… I had trained in high school as a draftsman. Give me a T-square, two triangles, a nice drawing board, and couple of sheets of vellum and I can draw a complete set of floor plans for your house (well… I could in 1980… maybe not so much now). But freehand, I am hopeless.

So when I tried to create a nice visual representation, and failed, I thought it was because of my lack of skill as an artist. I couldn’t have been more wrong. Regardless, the best I could do, at the time, was to follow the guidance in “Beyond Bullet Points” and create PowerPoint presentations that were compelling using emotive photographs. They were nice, but they weren’t the things I wanted to create.

Meanwhile on the other side of the Atlantic

Turns out, I was part of movement of sorts. A growing number of people had taken up the challenge of creating interesting visual representations of complex information. The “infographic” movement had started, and companies were springing up here and there to provide clear, simple, and compelling explanations of complex information. On the other side of the world, in the UK, an enterprise architect named Martin Sykes had begun his own journey, around the same time as I had. Big difference: he didn’t give up.

If you ever get a chance to meet Martin, you will enjoy his company immensely, just as I do. Martin is clever, thoughtful, easy-going, and funny. He’s a systems-thinker and an excellent speaker. Martin was also influenced by Tufte, but he continued on to find many other authors and designers who were publishing and writing about this new way of doing things. Martin started creating his own single page explanations of otherwise complex information, building up his skills and collecting techniques along the way. And, Martin took the time to learn how to draw. That didn’t hurt.

I met Martin Sykes through a mutual friend, Gabriel Morgan. Gabriel had joined the Enterprise Architecture team in Microsoft IT just a few months after I did, but he came to the practice from his work as a consultant using Microsoft Motion (later renamed Microsoft Services Business Architecture or MSBA). Gabriel had met Martin a few times, and had seen some of the visualizations that Martin used to explain business architecture. Gabriel worked with Martin to set up a workshop, for our team, to learn some of these skills. And in late October of 2007, Martin flew to Redmond and spent a week teaching us how to “tell stories” using a series of visual metaphors. At the time, he called them “Big Pictures” but that thinking evolved and we now refer to these creations as “visual stories”.

Can we do this again?

During Martin’s workshop, each of us created a visual representation of some idea or story we wanted to tell. Martin had distilled his own personal techniques into a FIVE DAY COURSE on creating visual stories. He walked us through ample examples, storytelling exercises, and a fairly simple process that he used to create visual stories. I created two visual stories in that class, one of which Martin still uses today… as an example of what NOT to do in a visual story!

The five day class happened once. Over the next few years Martin did four one day classes at different companies where he had been asked specifically to do more following a series of 90-minute presentations he had done at internal and external conferences. But the ideas were not “catching fire”, in large part because Martin was just happy to use what he was learning and focus on his day job of making change happen.

Meanwhile, I kept using his materials, and referred often to the binder full of PowerPoint slides that he provided. I practiced a few times more, and then stumbled into success. I created a visual story to explain an enterprise architecture roadmap to the Vice President of Operations. I presented the one page visual, and the meeting went fairly well. We got the sponsorship we needed. What I didn’t discover until later: that same Vice President took my one-page presentation and gave it to Steve Ballmer, CEO of Microsoft and one of the most powerful businessmen in the world, to explain how Microsoft’s Operations Division was attacking a key problem within the company.

That single page told a story. It was not a bunch of data. It was not a bunch of clever graphics. There was no hand-drawn art. It was a careful construction created using Martin’s techniques, and it changed my career. I was promoted and over time, I was leading a team. I wanted to bring Martin back to our group to do another one of these fantastic workshops, so that more of us could learn his techniques. I was willing to teach it myself if I had to.

A book is born

My goal was to put on a workshop for the entire Enterprise Architecture team within Microsoft IT. I reached out to Martin and asked if he had ever updated those PowerPoint slides. Thus began a series of meetings that morphed into a book proposal. We planned to create something visually interesting, to use our own ideas to tell the story of how use these ideas. Martin reached out to a friend of his, Mark West, a talented artist and designer that had worked with Martin on creating some of his training materials. Mark was familiar with the process because Mark had lived it. And he can draw. (I’m understating rather wildly. Mark has spent time as an art instructor at a college in Seattle, in addition to running his own design firm. Mark is a change agent who masquerades as a very cool designer.)

During those early days, we simplified and clarified the process of creating a visual story, and we called it “CAST.” CAST is an acronym for “Content, Audience, Story, Tell” which are the four stages of the process. We created a simple “canvas” that anyone can use. During this past year, Martin has put together a couple of workshops in other parts of the company and has used them to work out the bugs. We call this canvas the “CAST model” and I have completely adopted it. It’s like a simple visual checklist that helps you remember and iterate through the steps to creating a visual story.

We still haven’t done that workshop for Microsoft IT. We decided to create a book that we could both use to teach anyone we wanted. We decided to focus on using these skills to simplify the process itself, and to make it easy for folks who, like me, are not artists. Note: in a professional setting, on projects that are funded to create compelling information, I strongly recommend enlisting the help of a visual designer… but for your own use, to explain your own information, you can follow the CAST process to do the trick. Just like I did.

The long slog

Anyone who walks the road from idea to a complete book knows that it can be a difficult and time-consuming effort. We had our moments when each of us thought that this whole thing was nuts. After all, there were so many good books already on business storytelling and good design principles. Couldn’t someone just read those books?

They could, but what I got from Martin, in that workshop in 2007, was not in any of those books. Martin didn’t change my career with a collection of art tricks and bits from a dozen books. What Martin gave me, and what we wanted to give our readers, is a simple step-by-step process that a non-designer could follow to create a USEFUL and COMPELLING single-page visualization. Not high art. High value.

We knew we had something unique… something that none of the other books and authors and workshops had built. We had something that the non-artists among us could use to be compelling and useful. We had a book about change, and making change happen. We had a book about stories, and using those stories to drive big changes, huge changes… using those stories to MOVE MOUNTAINS.

Most of the text was written between November of 2011 and May of 2012. Most of the artwork that infuses this book, on every single page, was created in the spring and summer of 2012. The book is compelling and visually beautiful. We treated every single pair of pages as a two-page layout, and each was hand constructed by Mark West. Our publisher, Wiley and Sons, created a new team, with about twice the normal book staff, just to assemble it. Wiley knew we had something unique, and they were willing to take a real risk on it. Our team at Wiley did a fantastic job. I’ve been a co-author before, but never had an experience anything like this one. The level of communication, collaboration, and shared iterative design was simply unprecedented. The Wiley team moved a mountain as well.

Sample of a two-page spread used in the book Stories That Move Mountains

What you will get out of this book

In case it’s not clear already, we want this book to be practical and useful. This is NOT an art book, even though there is one chapter that focuses on detailed visual elements like fonts, colors and layouts. This is not a typical business book either. There are no long expositions on financials or sales strategy or performance measurement. This is a book about change, and it is for ANYONE that wants to influence another person to lead a change.

What you will get out of this book is a step-by-step process to follow that results in a visual story. We walk you through numerous examples, showing how we use the CAST stages to create visual stories and there is a final chapter that literally goes end-to-end in creating another visual story. We provide advice, and hugely valuable nuggets from a dozen other books that fill out shelves in mine and Martin’s and Mark’s libraries.

Our references chapter is also a simple, clear, layout that focuses on a small and manageable list of excellent books for you to use if you want to “go deep” on any part of the process (you won’t have to, but just in case you want to). We are also committed to continuing the conversation on the book sister-site http://StoriesThatMoveMountains.com where all three of us blog and upload resources (including a downloadable CAST model template, like the one on the right). You can also find us on Facebook for a more socially-oriented conversation (www.facebook.com/storiesthatmovemountains) as well.

It should come as no surprise that both Martin and I are Enterprise Architects. The biggest value we offer our clients is helping them to build the case for change. But change can be anything. You could be changing a business, or a team, or a family, or even yourself. You can create a visual story for nearly any situation where you want people to remember, and connect, with your case for change.

Yep, it still works

I’ll give you an interesting example. I am currently volunteering my time to a professional organization called the “Center for the Advancement of the Enterprise Architecture Profession” (or CAEAP, pronounced “seep”). Through that organization, I have been assigned, by CAEAP, to work with another professional organization that they partner with: the “Federation of Enterprise Architecture Professional Organizations” (or FEAPO, pronounced “FEE-poe”). I’m working on creating an industry-wide perspective on Enterprise Architecture. I went to a FEAPO meeting just last weekend where I was working with people, in person, that I’ve only met one time before. They were all aware of my project, of course, but it was not, and is not, their primary focus. I couldn’t be sure that they remembered anything from the last time we’d met, in February. I decided to use a visual story to frame what would have otherwise been a boring status update.

On the plane flight from Seattle to Fort Lauderdale (five hours in coach, on a red-eye overnight flight), I filled out the CAST model and created the entire presentation. (I had no internet access on the plane, so the graphic images I used were all on my PC hard drive). The moment I landed, I drove to FedEx Kinkos, printed the visual story on nice, sturdy, 11×17 paper, and drove straight to the 8:30am meeting. When it came time to present, I handed out the sheets and we turned away from our screens and spoke to each other instead.

Later that evening, as we sat eating dinner at an upscale Surf-and-Turf restaurant, they were reciting back to me the humorous bits of the story that I told. The story stuck. It was memorable. As a result, everyone has a good idea of what I need from them, and what they need from me, because we had a simple compelling visual story to work from. (I’ll see if I can get a link to that document made available so that you, gentle reader, can see it. A thumbnail is on the right).

So yes, I think you should buy this book. I’d say that even if I didn’t help write it, but I did. This is our way of saying: it’s time to change the world. This is our mountain to move. Join us. The world needs change agents to be effective. You are a change agent. If we help you become just 5% more effective, what hurdles will you overcome? What innovations will you introduce? What problems will you solve?

These are interesting times.

Realizing the Agile Enterprise

November 2, 2012 by David Sprott

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.

Architecture and Reality

November 3, 2012November 1, 2012 by Richard Veryard

There are various confusing notions of “real” and “reality” circulating in the enterprise architecture world.

1. The idea that business people are only interested in things that are real.

2. The idea that architectural models represent some form of r…