• 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

Force.com + Visual Process Manager = Vanilla Layer Cake Theory

February 12, 2010 By brenda michelson

Salesforce.com just added a powerful new tool to its Force.com development platform, a Visual Process Manager:

“The Visual Process Manager brings the power of Cloud Computing to Business Process Apps. Now you can visually draw any business process and instantly deploy it in the cloud with no code, no software and no infrastructure.  The Visual Process Manager helps companies easily automate specific business process like call center scripting, sales quotes, and new employee on boarding.” 

According to a post on TechCrunch:

“The technology powering the Visual Process Manager is based on technology acquired from Informavores, call scripting startup Salesforce bought last year.

The Manager has several different components. The Process Designer essentially helps businesses sketch out applications with established set forms, questions, and choices, and logic components, like task assignments, decision trees, and approval processes. These components can be dragged and dropped into a visual process design diagram/ The Process Wizard Builder enables companies to design a “wizard” to help walk end-users, step-by-step, through their business process. The Process Simulator lets customers test out and review processes before they are deployed. And lastly, the real-time process engine will run all of a company’s sophisticated processes and provides realtime scalability.”

The Visual Process Manager introduction gets a bit deeper on functionality.  [emphasis is mine]:

“Using our cloud-based workflow software solution, you can specify the retrieval, creation, update, or deletion of any object in a salesforce.com application or any Force.com object (including custom objects). You can also call any Force.com API. In practice, this functionality means that sales and service agents can work with simple, easy-to-follow scripts—while underneath, embedded business rules and salesforce.com data drive what the agent sees and automatically update CRM records. These are textbook examples of successful workflow software applications.

After you’ve optimized a specific process using the Visual Process Manager workflow software tool and the process is running inside your salesforce.com application, operations become much more efficient. The newly automated workflow carries out all the administration work behind the scenes. It may control the interaction of an agent in a call center or a customer on a Web site, as it silently interacts with other systems, processes, and Web services to deliver the required actions.

Because our workflow software tool is designed with integration in mind, you can link to databases, dialers, and IVRs; initiate workflows; control exceptional events or surge conditions; and handle the “stop and save” process required to manage escalations and call transfers. All in all, our workflow software frees sales reps and support agents from administrative grunt work, quickly giving them the situation-specific information they need for effective selling and top-notch customer service.”

As I read about Visual Process Manager, I was reminded of my Vanilla Layer Cake Theory paper from 2005. 

“There are classic rules of thumb used in buy/build decisions. Buy in situations of parity. Build for competitive advantage/differentiation. In a buy scenario, you willingly cede control of the end product (functionality, architecture, technology) for the promise of a lower price tag, ease of implementation, and quicker time to market. For success, you must actually cede that control—in other words, no modifications. But, that’s not always realistic. So, how can you reap the advantages of a buy, while providing a solution that actually fits your business (modifications and extensions), without getting trapped? Think Vanilla Layer Cake.”

An excerpt published on elemental links, November 2005:

“The vanilla layer cake theory is simple. Do vanilla (out-of-the-box) installations of all new application packages. Then, customize and extend the application functionality using abstraction layers, rather than in the application package itself.

[Click on picture to enlarge]

 

In essence, the application package installation performs the role of a provider in a service-oriented architecture. In some ways, the application package is more valuable for its building blocks, than how the vendor assembled it.

The abstraction layers implement your business architecture, in the form of an enterprise information model, business services, business scenario composition (process, events, service orchestration), and user interaction (portal, user interface, unified in-box).”

Of course in the SaaS world of Salesforce and Force.com, you can skip the “Do vanilla (out-of-the-box) installations of all new application packages” step, and proceed right to “customize and extend the application functionality using abstraction layers”.  Now, that’s intriguing… 

For those with a sense of nostalgia, you can read the entire Vanilla Layer Cake Theory on ebizQ.  Otherwise, dig in at Salesforce.com.

 

[Cross-posted from Elemental Cloud Computing].

Filed Under: bpm, business-driven architecture, cloud computing, enterprise architecture, integration, services architecture

Elemental Links: 2010 Plans

January 4, 2010 By brenda michelson

Having already stated my sole 2010 prediction, I want to start the year (decade) by sharing my 2010 plans.   For context, I need to start with my firm, Elemental Links.  The elevator speech:

Elemental Links helps organizations develop business-technology strategies, architectures, and programs to increase business visibility and responsiveness, optimize capability delivery, and enable innovation.

This said, for 2010, my writing, services and workshop offerings will center on the technology strategies, architectural approaches, business-technology programs and techniques that contribute to increased business visibility and responsiveness, optimized capability delivery, and business innovation.

From a business-technology perspective, the above translates to these topical areas:

  • Active Information Strategies
  • Business Architecture
  • Business-IT Integration
  • Cloud Computing
  • Enterprise Architecture in the ‘New Normal’
  • Event-Driven Architecture / Event Processing
  • Services Architectures

The topic list maps to writings, services and workshops as follows.

Public writings and client-based advisory services will cover each topic, the topic interconnections, and the ties to business forces, actions and value. 

On-site workshops are available in the areas of cloud computing, enterprise architecture, event processing / event-driven architecture and services architectures. 

2010 WORKSHOP PROGRAMS

Cloud Computing:

  • Cloud Computing Considerations for Enterprise Practitioners

Event Processing / Event-Driven Architecture

  • Event Processing / Event-Driven Architecture Introduction
  • Event Processing / Event-Driven Architecture Jump-start
  • Event Processing Business Analysis, Flow and Network Design

Enterprise Architecture:

  • Enterprise Architecture in the ‘New Normal’ Introduction
  • Enterprise Architecture in the ‘New Normal’ Jump-start

Services Architectures:

  • Business-First Service Analysis Techniques
  • Sustaining Services Architecture Success

Consulting services concentrate on three specialization areas: enterprise architecture in the ‘new normal’, event processing / event-driven architecture, and services architectures. 

For more information on any of the above, visit the Elemental Links business site or contact me.

In addition to my current publication venues – elemental links, business-driven architect and elemental cloud computing – I’ll be writing for OMG’s Business Ecology Initiative. 

As well, I have another topical research offering in the works, and perhaps (finally) the first seeds of a book, more on those later.

I have a good feeling about 2010.  I hope you do as well. 

Filed Under: active information, business architecture, business ecology, business-driven architecture, cloud computing, Elemental Links, enterprise architecture, event driven architecture, services architecture, soa

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

  • Harshest editorial feedback I ever received “stultified and like death”… (wildly popular paper, as it turned out):… https://t.co/qWNwBCOS5i February 28, 2023 2:16 pm
  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
© 2004-2022 Elemental Links, Inc.