• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

past is prologue: fluid enterprise, blended architecture

November 19, 2013 By brenda michelson

In what feels like eons ago, I wrote the following (excerpt) in 2004. The architectural strategies I refer to are SOA, event-driven architecture, process-based architecture (BPM), Grid (morphs to Cloud and IoT) and real-time, right-time (morphs to fast data, operational analytics).

I was thinking about this today as I contemplate (circle) my technology infusion work and current industry hype and practices.

From below, the ideas of architectural blends, business interaction patterns, fluid enterprise attainment, multi-use assets and architecture for execution hold firm.

“…Organizations shouldn’t be looking at these strategies in isolation; the strategies need to be considered collectively. The strategies should be mixed, as part of an architectural portfolio. Then we can select the right architectural strategy in each situation. But we shouldn’t stop there. With merely a menu of strategies to use, we need to take the next step.

We need to blend the strategies to work together, so we can seamlessly use different architectural strategies within the course of a business interaction. Now when our most important customer places an order, using our service-oriented Web site, the notable event not only informs us, but also invokes a promotions service, which tailors a special offer for that customer. We can send the customer this offer via email, or it can be available to her as a business-process-in-waiting, activated when she makes her next contact with us—in person, on the Web, or on the phone.

This is the true promise of the architecture strategies, used together to create what we call a “fluid enterprise.” In a fluid enterprise, lag time is squeezed, traditional organizational boundaries are dissolved, supply chains are optimized, information delivery is sped up, and attention is focused at the edges—where the customers are.

While this blended approach can bring great power to our businesses, it won’t help us one iota if it is executed poorly. We can’t take on this enterprise architectural blending activity with a traditional enterprise architecture mindset. We need more than a blueprint to make this happen—we need a realized architecture that can be easily used by projects. We need our architecture to be actionable.

But it isn’t just our architecture practices that need adjustment. We also need to think differently about our portfolios: business solution, information, and infrastructure. These new architecture strategies augment what is in place. Their power is in connecting and altering the behavior of existing assets. For example, as inventory is received in a warehouse, a content management system can be automatically reposting the product page for the received product that had been out of stock. The assets in our portfolios are no longer sole-purposed applications or databases; they are also potential multiuse components and triggers to be exploited in the new architecture.”

via business-driven architecture : elemental links : Page 3.

Filed Under: business-driven architecture, business-technology Tagged With: 2015IT

McKinsey Agrees: Outcome of EA is Change-Friendly Capability Delivery

April 13, 2010 By brenda michelson

McKinsey just published a new report, Why business needs should shape IT architecture, which speaks to taking a new approach to Enterprise Architecture programs.  An approach that is business-driven, capability centric, and change aware.  In other words, McKinsey echoes my mantra, “The ultimate outcome of enterprise architecture is change-friendly capability delivery.”

My ego aside, the McKinsey report is very good.  It sets the context for Enterprise Architecture Management, provides a CIO checklist for revolutionizing Enterprise Architecture Management, and walks through an example of EAM revolution at a diversified global investment bank. 

From my perspective, the most important point on the CIO Checklist is the first one:

“Focus on transformation.  Educate leaders at the highest level to help them understand that EAM is about change management and not simply a new IT initiative.”

Ultimately, the goal of your enterprise architecture program is to enable your organization to adapt to, and introduce, change.  Challenge your thinking with the following.  How can your architecture, or architecture program, be ‘intrinsically adaptable’?

Returning to the McKinsey article, the case study has many good insights.  I’m calling out two here.  For the rest, read the article.  [Emphasis is mine.]

The first is the use and business payback of capability analysis:

“Place business capabilities at the center

The bank’s merger history meant that the current organization comprised very different corporate cultures and a portfolio of independent IT fiefdoms. Unifying and improving the underlying group architecture became the EAM program’s primary objective. To achieve it and avoid past problems, the CTO conducted a series of workshops in which he brought together architecture teams from all the business units to develop an architecture that would not only support local needs but also serve as an optimal solution for the company at large

A well-tuned EAM effort concentrates on a core set of business capabilities, such as payroll, payments, or automated statement processing, where efficiencies and improvements can have the widest and most lasting impact. As a first step in the reform campaign, the IT department mapped the bank’s current state, charting the jumble of platforms, hardware, software, and network applications in use at the time. To winnow them, the department needed to understand the key requirements for each business line.

The new approach redefined the application architecture by using business domains, which regrouped the bank’s IT—data, processes, and applications—according to the business capabilities each business line needs. The chosen domains ranged from client services and product management to transaction processing, HR, and legal. The product-management department, for instance, must be able to examine account information on an integrated basis to see how well a given product is being received in different geographies and customer segments. It must also access credit, deposit, and payment data to calibrate margins, set pricing, and fulfill its reporting obligations. Within the overall product-management domain, subdomains for accounts, credits, payments, and settlements were established to consolidate, house, and manage those programming requirements efficiently.

By using domains and subdomains as building blocks, the architecture team reorganized the bank’s architecture around core capabilities, pooling shared applications and carving out any remaining requirements that needed customized support. To the surprise of the banks’ leaders, of the 100 or so domains the team identified at the outset, only 20 percent required applications specific to business lines. The rest—core functions such as settlements, payments, and central IT—were shareable. Rather than having different systems for securities processing in each business line, for example, one domain could centralize and maintain a standardized program for all business units. This approach freed developer and support-staff time for other high-value initiatives. The simplified framework cascaded downward through the entire architectural framework, allowing for a more efficient use of infrastructure.”

The second is EA communication techniques, and therefore, EA sales success:

“Make change sustainable

A good EAM program uses plain business terminology to guide the development process and create a sense of business ownership. Otherwise, the program may confuse or, worse, alienate the business audience that its changes are intended to support. In the case of one bank unit, an initiative to develop a new payments environment was rejected by the board leadership. Marking the culmination of a three-year effort, the proposal contained 300 gigabytes of detailed architecture information. Despite that bulk, the presentation lacked the one thing that would have made the project intuitively understandable to top managers: an executive summary telling them the overall program goals and laying out the financial and nonfinancial benefits.

Determined to correct the problem, the IT team put aside the small print and binders and turned to simplified graphics that highlighted key management questions. Managers in the bank’s payments businesses had been uneasy about restructuring domestic, regional, and cross-border transactions, so the IT team described the new architecture design’s business benefits in a succinct executive summary. Using a simple before-and-after graphic, the team showed how a fragmented architecture with over 200 different payments systems could be streamlined into a more integrated, cross-border IT environment…Now that everyone was on the same page, the merits of the program could be discussed robustly, and it won the board’s approval.”

As you pursue your own EA work, consider your role in business change.  Is your EA a change catalyst, or change impediment?  If it’s the latter, how will you revolutionize your EAM?

Filed Under: business-driven architecture, enterprise architecture

Enterprise Architecture in 140 characters

February 17, 2010 By brenda michelson

Last Thursday, I barged into a Twitter conversation on the “ultimate outcome of Enterprise Architecture”.  The conversation was related to Forrester’s Enterprise Architecture Forum in San Diego, which I missed due to the blizzard at JFK.  @Dcoon posed the question: “Is consolidation and centralization the ultimate outcome of EA?”

While consolidation and selective centralization are milestones on an Enterprise Architecture journey, I don’t believe they represent the “ultimate outcome”.  Enterprise Architecture needs to play a linchpin role in advancing the business. 

As such, I offered my 140-character perspective, edited for readability, as follows: “The ultimate outcome of Enterprise Architecture is change-friendly capability delivery.”

But, that’s my perspective.  What do you think?  Do you agree?  If not, what is the ultimate outcome of Enterprise Architecture?

Filed Under: business-driven architecture, enterprise architecture Tagged With: archive_0

  • 1
  • 2
  • 3
  • …
  • 9
  • Next Page »

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • Finding the lead refills and simultaneously misplacing the mechanical pencil appear strongly correlated. Yesterday at 4:30 pm
  • If it’s taking 20+ years to define the thing, maybe it’s not actually a thing... February 25, 2021 5:29 pm
  • Adventure Tourism for your brains. (credit to the esteemed @ruthmalan) https://t.co/7Z9478WagA February 24, 2021 3:49 pm
© 2004-2021 Elemental Links, Inc.