Sorry, Kids: APIs Have Not And Will Not Kill SOA

As I move about the industry talking about APIs (application programming interfaces) and the API economy — which hold important and transformative business opportunities — I’m frequently confronted with disparaging remarks about SOA (service-oriented architecture), as if it’s passé, gone, finito. It’s often in the way of (uninformed) assumptions about SOA. I hear things like, “SOA failed because it was too difficult” or “People do REST APIs now, they don’t do SOA” or other such bunk.

I’ll be the first to extol the importance and benefits of APIs, but the tales of SOA’s failure and demise are simply wrong (I really do like APIs; see this report). I had a powerful reminder of all this while attending IBM’s IMPACT conference this week. First off, I arrived late to one customer’s plain-vanilla “this is our enterprise SOA journey” session only to be refused entry because the room was over capacity. Glancing over the conference program, there were at least eight such sessions representing four continents and at least five vertical industries. I attended five of them and also had lunch with another SOA leader. The stories could all be summarized by the following plot line:

  • We saw the value in SOA. Whether the need was multichannel customer engagement, faster time-to-market, retiring legacy, getting past complex and costly point-to-point integration, dealing with duplicate applications, or some other business-technology problem, a core team recognized that SOA could make things better.
Read more

Are You Doing Techie Integration Or *Business* Integration?

“Figuring out how to think about the problem.” That’s what Albert Einstein said when asked what single event was most helpful in developing the Theory of Relativity. Application integration is a problem. A big problem. Not to mention data, B2B, and other domains of integration. As an industry analyst and solution architect, what I’m most interested in first is how to think about the problem.

Pop Quiz: The Goal of Integration

Which of the following statements best articulates the goal of integration strategy?

  1. The goal of integration is to keep data in sync across two or more siloed applications.
  2. The goal of integration is to improve business outcomes by achieving consistent, coherent, effective business operations.

The correct answer is B. Was that too easy? Apparently not, because most of the integration strategies I see are framed as if the answer were A. Most, but not all — and it’s the ones framed around B that I’m most interested in. Here’s the difference:

  • A-style integration centers on technology. It begins with data and business logic fractured across application silos, and then asks, “How can integration technologies make it easier to live with this siloed mess?”
  • B-style integration centers on business design. It begins with a businessperson’s view of well-oiled business operations: streamlined processes, consistent transactions, unified tools for each user role, purpose-built views of data, and the like. It designs these first — that is, it centers on business design — and then asks, “How can integration technologies give us coherent business operations despite our application silos?”
Read more

Digital Customer Experiences: Integration Opens A World Of Optimization Possibilities

What if you could look over the shoulder of every one of your customers as they used your mobile apps, web pages, kiosks, and other digital channels? What could you learn? How might you use what you learn to dynamically adjust your digital experiences?

In the days when web applications were king, this type of insight was doable with simple web analytics and similar tools. Today, continual experience optimization is much more difficult because of:

  • Multiple interaction channels. You must collect, correlate, and analyze data in a coherent way across multiple channels of customer interaction. A single customer interaction may cross between channels or even use more than one channel at the same time.
  • Many back end servers. You must integrate data from multiple back end servers including recommendation engines, commerce, mobile application servers, digital asset management, community, collaboration, messaging, and more.
  • The need for rapid change. You must quickly change any or all of your digital experiences and back end services based on what you’ve learned.
  • The need for contextual experiences. You must use each individual customer’s context to dynamically adjust experiences in real-time.
Read more

Digital Business Design Is The New Integration

If your organization is like nearly every other one I've talked to in the past 20+ years, you have a spaghetti chart of integration connections between all the siloed applications that run your business. Your customer is fractured across five applications. Your fulfillment process is broken across eight applications. Just try to pull together the data necessary to tell how profitable one of your products is. Or, as you implement mobile, external APIs, custom B2B connections, and more, how will you provide consistent, coherent access to your transactions and data?

Making sense of all the mess has been an important priority for years. The question is "how?" Forrester's latest research finds that it's time for a new kind of integration strategy. We call it "Digital Business Design":
A business-centered approach to solution architecture, implementation, and integration that brings business and technology design together by placing design priority on user roles, business transactions, processes, canonical information, events, and other business aspects that embody a complete definition of a business. 
 
Here's what we mean:
Read more

Products Are Going Digital -- What Leading Examples Are *You* Seeing Out There?

Here's a flash of the blindingly obvious: More and more products are going digital. You know this, but what I'm interested in is how they are going digital and to what degree. I see three major aspects: (1) the product itself becomes digital; (2) a physical product adds digital technology; and/or (3) processes and context around a physical product become digitally infused. Let me offer a sort of continuum of examples, and then I want to ask a question:

  • Music (nearly 100% digital). The greater part of music bought these days is in the form of a 100% digital product. 
  • Health band. With a health band (e.g., Fitbit, Nike FuelBand), I don't really care about the physical product, but I'll put up with it to get the digital benefit: lots of data (and more) about my workouts and health.
  • Cameras. A digital camera is a physical product that uses a combination of physical and digital technology, and I actually care about some of its physical design (e.g., lenses). It produces a 100% digital artifact (photos), and the process around the photos is digitally infused.
  • USB picture frame. Part physical, part digital. By replacing the center of a picture frame with a digital screen, I get a new twist on an old standby. But, working with the digital part still requires a high degree of physical manipulation (carry a USB drive to the frame, etc., etc.).
  • WiFi picture frame. Part physical, even more digital. The WiFi bit bumps it way above a USB picture frame in terms of seamless integration into a digital world. I can email a picture to the thing, or maybe tag a photo on Facebook and suddenly it shows up.
Read more

The Big Mistake With Business Architecture

There’s a big mistake often made with business architecture — a very big mistake, yet a very subtle mistake. As you might expect, there are a number of mistakes one might make with business architecture, but there’s a particularly big and common one that multiplies its effect through all the others.

The mistake is this: To position business architecture as a new layer on top of your existing processes and structures for EA domains such as application architecture, information architecture, and infrastructure architecture.

Here’s the issue: The traditional way many organizations have pursued EA, it should have been called “enterprise technical architecture” — ETA. The central focus has been on the likes of technical standards and reference architectures for application implementation — i.e., on the technology — and not on the enterprise itself. In a phrase, ETA is “technology-centered,” leading us to odd behaviors like assuming it’s only natural that business users, product data, customer data, and the rest will be fractured and split across multiple applications. We put applications at the center and make the business gyrate and adapt around our siloed and broken applications.

Read more

The Fallacy Of Architecting Behavioral Change With Social Technologies

 

Social networking is hot, and it’s smart to think about how your organization might use it to generate benefit equal to the market hype. As you develop your social technology strategy, it’s particularly important to steer clear of a fallacy of thought that often creeps into technology strategies for enterprise communication and collaboration.

Oftentimes, an enterprise social strategy, like enterprise collaboration strategies before them, will have among its goals a phrase suggesting that the technology should “change the way people communicate.” Superficially, this phrase may accurately describe part of the effect, but at a more fundamental level, it violates a very important change management principle. To make my point, I’ll back up and start with a little history.

I used to communicate via paper memos and phone calls, but it was cumbersome and time-consuming. Email has come to replace much of that. So, the “way I communicate” has changed, right? On the face of it, yes, but, looking more closely, not really, at least not at first. Compared to my “before email” days, I still communicate the same types of things with the same kinds of people — only email made these communications easier (for the most part). I started using email because (1) it could improve the existing way I communicated and (2) it fit my work and life context — it was just a new program to use on my handy desktop PC. Once email became part of my context, I realized that I could use it for communications that were too costly before. At this point, it did, to a degree, change the way I communicate.

Read more

Get On Board: A Copernican Shift In The Focus Of Your IT Delivery

Step back and think: How would you answer the question, “What does your IT group deliver to your business?” Your answer will indicate how you think about the relationship between business and technology, and, in turn, it will affect your business agility and your business-IT alignment.

If you answer anything close to “IT delivers and integrates solutions to meet business requirements,” your mental model boils down to thinking that your solutions support the business: Business is one thing; solutions are a separate thing. If the business has a problem, let it come ask IT for some application to address the problem — maybe IT will even help the business figure out what it needs. Each application supports (typically overlapping) parts of the business, and IT performs whatever behind-the-scenes integration is necessary to gain some degree of coherency across the whole. The result is the sort of siloed spaghetti application mess that most organizations are dealing with — even if SOA and BPM and the rest make it easier to deal with.

Read more

Business 2011 Gets Faster; Business Rules And SOA Policy Get More Important

Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.

Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.

Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.

Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.

Read more

Build Innovation Zones Into Your Architecture

Forrester’s recent book, Empowered, describes the type of technology-based innovation by frontline employees that can cause nightmares for enterprise architects. New tools for business innovation are readily available to anyone, ranging from cloud computing and mobile apps to social networks, scripting languages, and mashups. Faced with long IT backlogs and high IT costs, frontline employees are building their own solutions to push business forward.

What worries architects is that (1) solutions built with these new tools — with little or no vetting — are being hooked to enterprise systems and data, opening potentially big risks to reliability and security, and (2) the siloed, quick-hit nature of these solutions will drive up ongoing costs of maintenance and support. Traditionally, architects use enterprise standards as their primary tool to ensure the quality, efficiency, and security of their organization’s technology base. However, when applied in the typical “lockdown” fashion, standards can stifle innovation — often because vetting a new technology takes longer than the perceived window of business opportunity.

To deal with these conflicting pressures, architects must forge a new equation between responsiveness and technology control. The business value of responsiveness, combined with the typically limited size of enterprise architecture teams, means that most organizations cannot wait for architects to vet every possible new technology. Thus, you must find ways to use architecture to navigate the tension between the business value of responsiveness and the business value of a high-quality technology base. The key is to build innovation zones into your architecture; Forrester defines these as:

Read more