Dec 6, 2011 12:28 PM
What should EA do for business agility?
-
Like (0)
About Forrester
Forrester Research, Inc. is an independent research company that provides pragmatic and forward-thinking advice to global leaders in business and technology.
What should EA do for business agility?
-
-
-
-
Thanks, Eric. The elaboration on your thoughts is helpful.
- Like you, I find the notion of measuring agility to be foundational. My colleague, Henry Peyret, has published on this (e.g., "Updated Q2 2011: Assess Your Enterprise Agility" http://www.forrester.com/go?docid=58894). Also foundational is your focus on portfolio management. One's application portfolio is an important focus, yet I find it more critical to move above app portfolios (which is a tech focus, and can reinforce app silo thinking) and think in portfolios of business design points (processes, transactions, user roles, policies, rules, events, etc.) that tend toward unification across app silos (e.g., a business transaction definition may remain constant while one goes from five legacy apps to three to one in a consolidation effort).
- Love the scenario analysis bit. Back in the nascent days of OO, some talked of doing "change cases" to accompany "use cases" -- I think we all the more need such analysis methods, and at both the business and architecture levels.
- Hmmm -- I think we agree but I'm not sure. I agree that reference models cannot to-the-core be static and frozen. However, if core architecture structures are always changing, I believe it would lead to constant reworking of architecture at the cost of the agility that architecture was supposed to create. Thus, for architecture to add business value over the long haul, it must from the start anticipate the fundamental ways in which business and technology change, so that the the changes, by and large, fit within architecture structures. An analogy I've used is that, after the first semblance of a modern automobile was created (Daimler and Benz, separately, in the 1880s), it took about 40 years for the structure of the modern automobile to solidify. Since then, there have been many, many innovations within that structure (and the processes and industry landscape around that structure), but the core structure of the automobile has not changed since the 1920s. We want the same now for EA reference models.
-
I totally agree with #1 above. The idea of portfolio management/rationalization takes place in all domains (think: TOGAF) of an EA. If we don't rationalize the "parts" of the business architecture, then we are just automating (and masking) inefficiency. I can't help but draw on the roads in Boston: "paving the cow path".
-
-
-
-
I think you meant bold assertion, rather than bald assertion, although there's plently of assertions that make us want to pull our hair out. I guess that would be a bald assertion.
I don't know that I completely agree with your assertion, mainly because it's highly dependent on where agility is needed. I really like Eric's comment about Wayne Gretzky, however. The better a company is able to recognize the areas where it needs to change and execute that change effectively, the more likely it is to succeed. If you're just one second ahead in "business time," that can be a huge advantage. Keep in mind that the business clock ticks far faster now than it did in the past, and we can only assume that it will continue to get faster. The accelaration rate may near zero from time to time, but it will never go negative.
Regardless of the area in which agility is needed, my answers to your questions all come down to one thing: decision support. Everything we do as architects needs to be in support of making good decisions. A reference architecture is a representation of what someone believes is sound decisions in a particular area. The challenge that organizations have in achieving agility is two fold. First, is simply the ability to make decisions and follow them. How many organizations continue to expend effort in challenging a particular decision, or in simply having unclear decision authority? How tolerant is the organization of decisions that didn't work out? This brings us to the second part of this. The criteria with which we make decisions is always changing. What I see over and over again are arguments over particular options that turn into religious debates. The reason for this is because there's a fundamental disagreement on the decision making criteria. Get people to agree on the criteria with which we make the decisions and progress can be made.
Getting back to agility and architecture, any architecture has been established according to some set of important criteria. When those criteria change, the architecture must change with it. Does someone have the job of looking at the decision making criteria on a regular basis, keeping a pulse of all the forces that come into play, and triggering adjustments accordingly? And can you do it a second faster than your competitors? On this, here's a more concrete example. If you have documented an enterprise capability map, do you have a set of criteria for making decisions in each of the capability domains? Some criteria may universally apply across all domains, others may be specific to a particular capability. Is the only time you visit those criteria when a new project comes along and needs that particular capability? That's a very reactive approach. I would not consider a reactive organization to be agile, I would expect an agile organization to be proactive.
Once you've done this, can you execute those changes effectively, or do you become mired in debate over whether the criteria should have changed or not? If you have fear of executing a wrong decision, you won't be agile. Risk tolerance should be part of your decision criteria to begin with. Decisions need to be made based on the company's tolerance for risk, not on the individual's tolerance for risk (if I do this, will I get my bonus?).
As I write this, however, it still comes back to Eric's Wayne Gretzky comment. We can put in place scheduled processes to ensure decision criteria get refreshed on a regular basis, and adjust the architecture accordingly, but all it takes is one new trend, event, or force that isn't considered. There will always be people who see thing a second before everyone else, or see things that no one else saw. Keep in mind however, that an agile company must see the opportunity and successfully execute that opportunity in a time frame faster than its competitors.
-
Thanks for the well constructed questions. If this turns out to be a rather long read, thanks for your patience and time in advance.
I will state how I view agility and then answer the four questions from that perspective.
(1) -- agility is the ability to fail-fast.
(2) -- agility is the ability to recover from a failure and change direction with the least amount of resources.
(3) -- agility is the degree of freedom to make mistakes and not be punished for experimentation.
(4) -- agility is about delivering small improvements at a consistent pace. The pace of improvements is more important than the size of improvements.
(Bullet #3 above reflects the mindset and culture of an organization. The assumption here is that a confident organization is secure enough to let its core resources experiment and make mistakes.)
Q1: If EA is truly responsible for architecting the *enterprise*, what specific and concrete actions should EA take in response to the need for business agility?
(a) -- Since EA has the vantage point with a 360 degree view of the organization in business and technology terms, EA should guide projects to be designed with #1 and #2 as stated above. To be specific, EA should promote generic architectures for typical use-cases the organization deals with. For example, take integration needs with multiple SaaS vendors outside the organization. After some study, one can identify the choke points that can cause the business functions to fail. Identify these and make them fail-fast.
(b) -- Stress on simplicity. The simpler the architecture, the better it is understood and greater the likelihood of recovery from failure. For example, systems may not need to be highly available on day one across multiple data centers but the project may need it in the future. Plan for high availability down the line but deliver the functionality in small increments and scale up over time. It is simpler to deliver in small well understood increments for one data center and scale over time. (#4 above)
(c) -- EA should partner with "Just In Time" incubation teams that are very small in terms of head-count and reports directly to the CTO. The Incubation team and EA collaborate with EA taking a backseat in terms of governance and process to let the incubator experiment in sandboxes. The Incubator reports back to the Architecture Review Board(ARB) with findings whereupon the ARB can plan on how to integrate the promising findings into its end-state architectures. (The Just-In-Time team stays in action only for a few months and is then dismantled.)
(d) -- EA must stop speaking in metaphors and instead be precise and concise when they communicate within the organization. This becomes even more critical in an agile scenario. EA must drop the ivory-tower lingo.
Q2: How should the need for business agility affect the overall architecture strategy by which EA guides the organization?
(e) -- There would be nothing more disappointing than EA being perceived as another necessary-evil; bureaucratic-path that hinders an organization's agility. If organizations have to become more agile, a rotation policy should be in place to get business, solution, and enterprise architects participate in real Scrum projects at least twice a year. The insight gained by EA this way will beat 200 meetings where people white-board their lives away just to convey information. It is also less time consuming this way because business and application development do not feel burdened by the need to educate EA in extensive detail about their efforts. It infuses new blood into EA all year round.
(f) -- At the end of the day, no matter how large the organization, the number of architecture design options and the corresponding solution architectures will be a handful for a selected set of critical business functions. Take customer service for example, you probably have web, call-center, mobile, and Internet as channels irrespective of business. You can whittle down the architecture options across each of these channels to a few. Identify the areas of innovation that will affect the architecture and make the solution more modularized. For example, the user interface technologies are undergoing tremendous change due to the advent of mobile devices. So, think as to how you can provide a seamless UI across various channels; how can you architect customer service continuity in the various channels? By reducing the scope this way, EA can adequately focus its energies for the next 2-4 years.
(g) -- EA should make its deliverables more digestible and actionable. It should time its deliverables to mesh with the development efforts and release cycles of business and application development teams.
Q3: How should the need for business agility affect and infuse solution reference models promulgated by EA?
(h) -- By having business and solution architects actively working in a rotatory fashion, the solution architects act as a feedback loop bringing in valuable knowledge into the EA group to update and tune the solution reference models in a continuous fashion.
-- The solution reference models may not be implemented exactly by application teams as prescribed in a real scenario. There will be tweaks around use of protocols/libraries/design-patterns etc. There is a need to take a stance on what is not permissible keeping the end-state architecture vision in view. This will be a constant struggle in an agile scenario. Q4: In what ways should the need for business agility affect how EAs think about their role in the near- and long-term success of the organization?
(j) -- In the near term, the need for business agility also can significantly affect business processes which aren't as measurable as isolated technology solutions. There will be a need to constantly observe the changes in processes and their interplay with solution architecture as they can get out of sync if due attention is not paid.
(k) -- In the long term, EA should keep a close eye on its internal incubators and the emerging technologies to see if any disrupters could significantly change the long term EA vision. Particular attention should be paid to the evolution of core platforms and solutions that the organizations have invested in. For example, emerging SaaS solutions can change the integration and security design patterns. The long term EA solutions must be able to switch gears with the least amount of resources and as smoothly as possible.
(l) -- The goal of EA is to help deliver business strategy. Gatherings such as the Architecture Review Board (ARB) must be used to full effect to socialize the long and short views of EA and explain how they are aligned with delivery of business strategy.
