Application transformation targets enterprise bottom line with eye-popping ROI

Is 80% of your IT spend committed to maintenance? Are inflexible and expensive legacy applications suffocating your innovation? Is the unprecedented economic climate demanding that you take a step back and ask, "Now what do we do?" If you're like many of us, you answer these questions with a resounding "YES". And you aim to do something about it by tackling one of the primary contributors to corporate lethargy... the legacy application.

In his introduction of a compelling series on "the how and why of transforming legacy enterprise applications," Dana Gardner hosts Paul Evans and Luc Vogeleer from HP's practices for Application Transformation and Modernization.

To whet our appetite, the gang speaks to a case study with the Italian Ministry of Instruction, University and Research (MIUR). The case study explains how they were able to achieve significant ROI - millions of dollars in savings - in only 18 months by employing a multi-faceted strategy that takes a "very holistic approach and looks at the entire portfolio of applications." Depending on parameters such as the usage of the application, the business criticality, the frequency of changes, cost, complexity, etc, the team selects transformation targets and techniques that create quick wins - immediate benefit. And the "ROI and the benefits from those quick wins are immediately reinvested for continuing the transformation. So, transformation is not just one project. It's not just one shot. It's a continuous program over time, where all the legacy applications are progressively migrated into a more agile and cost-effective platform."

When it comes to large-scale transformation (or any large initiative for that matter), take note of the incremental approach focused on constant value creation.

Check it out at Application transformation case study targets enterprise bottom...

Effective Enterprise Architecture Capitalizes on Emergence

It's been interesting to observe the response to Gartner's recent discussion of a "new" approach to Enterprise Architecture. In the press release titled "Gartner Identifies New Approach for Enterprise Architecture," the analysts assert that Enterprise Architects must "respond to the growing variety and complexity in markets, economies, nations, networks and companies" by adopting a "new style of enterprise architecture" called "emergent architecture." And they describe seven properties that differentiate this "new" style from what they refer to as "the traditional approach to EA." While I find it curious that Gartner considers this a new approach, the analysts' guidance is sound and reflects the "state of the art" in EA leadership. In fact, it's the only style I've personally seen to be effective at all. Essentially, your EA practice should encourage the creation of an empowered organization capable of adaptive and goal-seeking behavior that maximizes effectiveness along the front lines of the business.

In this light, let's take a look at each of their seven properties of "emergent architecture."

1. Non-deterministic - In the past, enterprise architects applied centralized decision-making to design outcomes. Using emergent architecture, they instead must decentralize decision-making to enable innovation.

I've heard about this "deterministic" EA practice. And I've also heard about unicorns. Every effective EA practice I've seen recognized its role as one of leadership - and context. One of the biggest drivers in business today is Agility - the need to respond rapidly to changing needs and opportunities. By definition, then, we are operating in a climate where the future is not pre-determined or predicted. As such, at some scale, the specific outcomes are obviously non-deterministic. But there's a huge risk of this property being abused (see Agile Is Not "Make It Up As You Go"). As a whole, any organization with an EA practice absolutely has some destination in mind... some target. It's our job to create context and to provide leadership that helps the organization translate that target into actionable goals... and to adapt its way to success.

2. Autonomous actors - Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents.

Again, the idea that an Enterprise Architect could ever "control all aspects of architecture" is a farce. The power of an organization always lies with those that are serving the organizations clients - the business units. Our role in EA is to serve those people on the front line and empower them to better meet the needs of their customers - and at the same time advance the organization as a whole towards its targets. This is a role of leadership - not control - and I wrote about it in Leadership - The Secret Sauce. Emphasizing the value of "collective intelligence," that post reminds us that we can "achieve outrageous levels of performance by harnessing the intellect and energy of the people." This also came up in Nurture The Freaks where we contemplated these words from Gary Hamel, "Going forward, no company will be able to afford to waste a single iota of human imagination and intellectual power."

3. Rule-bound actors - Where in the past enterprise architects provided detailed design specifications for all aspects of the EA, they must now define a minimal set of rules and enable choice.

It's a reasonably well accepted principle that an EA practice should never make a decision (or set a constraint) that could be left to the business unit or development team. In fact, enabling choice and encouraging participation are important vehicles for gaining buy-in and goodwill (see Governance Without Goodwill Is Dead). This is yet another reminder of how we need to establish context by creating guard rails that keep the organization out of the ditch.

4. Goal-oriented actors - Previously, the only goals that mattered were the corporate goals but this has now shifted to each constituent acting in their own best interests.

With the guard rails in place, responsibility for driving rests on the individual drivers, each in their own vehicle with both hands on the wheel.

5. Local Influences: Actors are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No individual actor has data about all of an emergent system. EA must increasingly coordinate.

There is a massive amount of information flowing through the modern organization, and the majority of it originates and circulates right on the front line where the dynamic nature of today's agile organization demands a high degree of "in the heat of battle" decision-making. This suggests EA add value by encouraging a broad community that is willing and able to actively contribute to and consume a real-time, high-bandwidth stream of communication. It's not our job to assimilate it all and make decisions. Instead, as individual consumers at the trough of the information stream, we help drive the information out to those who need it the most. I don't really like the use of the word "coordinate" here. We're only coordinating in the indirect sense. Perhaps this role is some combination of the Connector, Maven, and Salesman roles described by Malcolm Gladwell in The Tipping Point.

6. Dynamic or Adaptive Systems: The system (the individual actors as well as the environment) changes over time. EA must design emergent systems [that] sense and respond to changes in their environment.

This is one of the most important functions of the Enterprise Architecture discipline in a modern organization. We have a responsibility to bring a "systems thinking" perspective to the table and influence the design of flexible and adaptive systems - systems that have the ability to learn from and respond to their experience. When talking about systems, here, it's critical that we deliberately design this adaptive nature into our products AND our organizations. I'm happy to see that Gartner is beginning to recognize organizations as a type of "complex adaptive system".

7. Resource-Constrained Environment: An environment of abundance does not enable emergence; rather, the scarcity of resources drives emergence.

Most of us are operating under the influence of unprecedented economic conditions, and these times demand that we become more creative. In fact, creative isn't really the right word. To respond to the reality of the corporate climate of today (and tomorrow), we're going to need to be "clever" - adroit, nimble, resourceful, and mentally quick. The organizations that thrive in the future will be those that respond today by building a sustainable system of Agile capabilities that maximize the contribution of every associate.

It's good to see Gartner lend its voice to the value of "emergence" in architecture. Gone are the days where a few of us at the top of an organization can see the future clearly enough to design a top-down response. For the past decade, nearly all the modern management and leadership literature has recognized that it's increasingly necessary to create empowered communities that respond to a vision with heart and passion. Organizations that adopt these principles are able to create, embrace, and capitalize on opportunities. As Enterprise Architects, our role is to help lead the establishment of that vision and create an appropriate context in which those opportunities are readily recognized and embraced with all the energy and intellect of the community.

Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3

Dean Leffingwell, author of Scaling Software Agility, recently posted a series on the ongoing debate over "Feature Teams" versus "Component Teams" in the Agile community. Over the course of three posts, Dean does a great job of digesting the underlying concepts and considerations, and he ultimately recognizes there's likely not "one right answer"... That like most things in software, we're dealing with various shades of gray, and arriving at the right answer depends on smart people with good judgment.

As he puts it:

"Given the advantages and disadvantages to each approach - essentially the balance of immediate-value-delivery vs. architectural focus and potential for reuse - the agile enterprise clearly leans towards the feature team approach, as there can be no question on the immediate value delivery velocity benefits and the focus of the teams."

"However, ... the answer is not that simple, and it's likely that a more balanced approach may be required."

Whichever way you slice it, make sure your teams clearly understand the results they are accountable for - be they intermediate components or full-fledged product features.

And for what it's worth, I strongly recommend you recognize the importance of organizing around the architecture. The alternative is allowing the architecture to organize around the organization, and that invariably leads to unintended consequences.

Check it out at Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3

Software Engineering: Dead?

Over on Coding Horror, Jeff Atwood pointed us to a recent publication by Tom DeMarco titled, "Software Engineering: An Idea Whose Time Has Come and Gone?" As Jeff points out, DeMarco is someone who has shaped the thoughts and minds of the software world for a couple of decades, and when he unabashedly claims that "software engineering" is dead... well, that falls under the category of "things that make you go huh!?"

Jeff does a nice job of putting DeMarco's comments into perspective and gives us all some things to think about. In particular, he encourages the focus on the "craftsmanship" aspect of our profession. This "passion for the craft" of software development is something many of us are enthusiastic about and spend a great deal of energy fostering within our organizations and teams. Jeff wraps it up nicely, concluding, "The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed. Everything else is just noise."

I'm not one to abandon the engineering disciplines - and I'm pretty sure that's not exactly what Jeff or Tom are suggesting - but it's high time we all recognize that much of what we do is a "craft." Crafts are performed by people who care about what they do. When engineering attempts to take the place of heart and passion... we fail.

Check it out at Software Engineering: Dead?

A Customer-Driven Architecture for Banks - Learning from iPhone

Glenbrook Partners discusses a recent report from Javelin Strategy and Research that elevates awareness to the changing behavior and expectations among electronic banking customers in the "iPhone-era". Javelin explains that these customers will tend to be much more interactive with their financial institutions and will insist on a greater level of control and visibility. In some ways, this report speaks to the shift underway in application design, but it applies that transformation specifically to the needs of online banking. All-in-all, this is another example of how consumers are (appropriately) shifting into a position of even stronger influence over the applications we deliver.

Check it out at A Customer-Driven Architecture for Banks - Learning from iPhone

Mistake Proofing and The Role of QA

Roland Cuellar at LitheSpeed recently highlighted some of the characteristics of the QA role and the importance of rethinking how this role integrates throughout the development process to add even more value. Taking a position similar to what I propose in "One Team - Developers and QA" (http://blog.softwarearchitecture.com/2007/04/one-team-developers-and-qa.html), Roland borrows from some common "Lean" practices and encourages a deeper relationship with development and a focus on keeping defects out of the product right from the start. Specific recommendations include more detailed and interactive communications/partnership and the elevation of test cases to first-class requirements.

Check it out at Mistake Proofing and The Role of QA

Enterprise 2.0 Isn't a Checklist

The FASTForward blog posted a nice perspective on "Enterprise 2.0" that deserves a look. Yes, this term (and the pursuit it represents) has its own set of risks, but it also embodies a shift in corporate climate that deserves clear focus and understanding. Summing up the purpose, Paula Thornton writes:

So what IS Enterprise 2.0 focused on? People: tapping the human potential, helping to change the way business gets done by optimizing it not to the systems but to the people. Not shaping the people (via training and documentation) to the systems and the business, but changing the systems and the business to optimize the potential of the people.

Under the heading of "How to get to 'Enterprise 2.0'", the article goes on to describe a number of the critical success factors:

1. Truly Utilize Resources - Determine the typical scenarios for problem solving and recognize that departments or hierarchies do not hold the answers to business problems/issues: people do.

2. Shorten Distances - Simplify all aspects of "doing" business. Repeatedly ask: What can we stop doing? Leverage what's working (from the perspective of all individuals impacted, not just those with "management" responsibility to execute) - bypass the rest.

3. Embrace Organic - Organic is not chaotic. Nature has order, but that order is under rapid cycles of repeated construction and destruction.

4. Shift Focus - It's not necessary or beneficial to make things "binary". Good designers are comfortable with the "squishiness" of heuristics.

5. Shift Thinking - Design Thinking requires a different approach: it focuses on trying out multiple possibilities (fail fast) to test an algoritm - a problem statement. Many solutions fail because they either 1) started with the wrong question (the solution is the answer to the question) or 2) did not adapt to change the question (the problem statement) as more was learned along the way.

6. Shift Culture - A company that has been optimized for "machine" design (command and control), will have a culture that reinforces such behaviors. Such a culture will undermine E2.0 potential. It will seek to eliminate the efforts as a "foreign body". A different culture is not a prerequisite, it's a corequisite.

Some things to take note of.

Check it out at Enterprise 2.0 Isn't a Checklist