We sure do talk a lot about enterprise architecture (EA) maturity. When I think about it, every piece of research we create is in some way intended to help EA leaders mature their practice. But alas, reading alone isn’t what matures an EA practice. Somebody, somewhere (likely, you) has the difficult task of implementing these EA concepts as processes, artifacts, methodologies, etc. And there arises the challenge: Simply building a “new thing” such as a business capability map or a set of reference architectures isn’t where maturity comes from. Rather, it’s about getting these “new things” out there, seeing them used, making sure they’re relevant, and realizing an impact.
For the many EA practices that want to evolve their practices toward a strategy- and business-driven role, actually getting that done means going outside of EA’s current scope. In order to execute on this vision, EA must consider three competencies to see them through their maturity journey, all of which are fraught with boundaries:
Insight. EA professionals need to be able to show that they have an understanding of their firm’s direction and their stakeholder’s strategies for navigating toward it. EA practices therefore need some procedure for gaining this insight — especially since most firms don’t articulate it well. But how can EA — which may historically be tactical and technology driven — get involved?
Influence. EA must now reach out to new stakeholders and use this newfound insight to influence their decisions. The challenge for many EA practices is to avoid blindsiding or overwhelming their stakeholders, as opposed to making their decisions easier. So what is the right way to approach new stakeholders and position your insight?
In our Forrsights Business Decision-Makers Survey, Q4 2011, we asked business technology leaders to rate IT’s ability to establish an architecture that can accommodate changes to business strategy. While 45% of IT rated its ability positively, only 30% of business respondents did. Clearly, both think there is room for improvement, but business is more concerned about it.
So are we agile? Only 21% of enterprise architects in our September 2011 Global State Of Enterprise Architecture Online Survey reported being even modestly agile, so I think we all know the answer.
What do we do about it? Continue to focus on technology standardization and cost reduction? Give up on that and focus on tactical business needs? Gridlock in the middle because we can’t make the business case to invest in agility? This is the struggle EA organizations face today.
To act with agility, firms must create a foundation for it, and three barriers can get in the way:
Brittle processes and legacy systems. We all know it this one; the current state mess of processes that cannot adapt to change and legacy systems where everything is connected to everything else, so even the smallest changes have broad impacts. Techniques to overcome this barrier include partitioning the problem into digestible pieces to show incremental progress and short-term payoff.
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.
There are many types of criminals. These include thrill-seeking hackers, politically motivated hackers, organized criminals after financial gain, and state-sponsored groups after financial gain and intellectual property or both. Any of these have the potential to break these capabilities through information loss, or denial of service. Business processes and their associated transactions need to look at information security as a key component of any architectural design we might create as Enterprise Architects.
Security architecture is dependent on the idea of “security.” Security by some definitions is the trade-off of convenience for protection. When I am unloading the car and have an armful of groceries, it's challenging to unlock the front door at the same time. Alternatively I could just leave the front door unlocked but that might invite guests I had not planned for. So I trade convenience for protection.
Security is often seen as in conflict with business users; however, security is a process that protects the business and allows it to effectively operate.
Security is in response to perceived business risks.
Security can be seen as a benefit and a business enabler and can aid organizations to achieve their business objectives.
Several recent Forrester reports home in on what we call “The Age Of The Customer” in which firms must seek to become customer-obsessed to build differentiation and loyalty. Those firms that embrace this will ramp up investment in four priority areas: 1) real-time customer intelligence; 2) customer experience and customer service; 3) sales channels that deliver customer intelligence; and 4) useful content and interactive marketing. All these needs are technology-infused – wholly dependent on technology and in categories where technology is evolving rapidly. Underlying these investments is the need to master the flow of data about customers: capturing/collecting data about them, analyzing it, distributing to those points of engagement, and, finally, integrating the insights into the customer experience.
Companies can’t succeed at doing this without a close partnership between the business areas leading the charge and IT. The rate of change of your customers, markets, business opportunities, and technology is simply too fast. Forrester is exploring this theme in our first CIO/CMO joint forum.
The reality, though, is companies flounder at this marketing-IT partnership. They flounder because of:
More ideas than capacity. A plethora of desired initiatives are constantly being surfaced – beyond the limits of available budget and with no mechanism to sort them into an achievable plan that IT can deliver on.
Just attended a Big Data symposium courtesy of IBM and thought I’d share a few insights, as probably many of you have heard the term but are not sure what it means to you.
No. 1: Big Data is about looking out of the front window when you drive, not the rearview mirror. What do I mean? The typical decision-making process goes something like this: capture some data, integrate it together, analyze the clean and integrated data, make some decisions, execute. By the time you decide and execute, the data may be too old and have cost you too much. It’s a bit like driving by looking out of your rearview mirror.
Big Data changes this paradigm by allowing you to iteratively sift through data at extreme scale in the wild and draw insights closer to real time. This is a very good thing, and companies that do it well will beat those that don’t.
No. 2: Big is not just big volume. The term “Big Data” is a misnomer and it is causing some confusion. Several of us here at Forrester have been saying for a while that it is about the four “V’s" of data at extreme scale - volume, velocity, variety and variability. I was relieved when IBM came up with three of them; variability being the one they left out.
Some of the most interesting examples we discussed centered on the last 3 V’s – we heard from a researcher who is collecting data on vital signs from prenatal babies and correlating changes in heart rates with early signs of infection. According to her, they collect 90 million data points per patient per day! What do you do with that stream of information? How do you use it to save lives? It is a Big Data Problem.
Greetings — thanks for taking the time to read my inaugural blog! Let me introduce myself by way of continuing a discussion that I started at Practicing EA and CIO.com on innovation and technology that I think strikes at the heart of our challenges as enterprise architects. It also provides a good context for my future research, which I discuss at the end.
Closing The Innovation Gap
In part 1 of this post, I claim that a gap opened while we were fighting the overly complex, expensive current state and trying to help our business partners innovate with new technology.
The gap – We cannot deliver new technology and innovation quickly or cheaply enough.
Shadow IT Is The Symptom, Not The Cause
The Symptom – We often blame Shadow IT and manual workarounds for increases in complexity, reduction in quality of service, and obscuring true technology costs. These are symptoms of the problem, not the problem itself.
The Cause – Business users know more about what they need and when they need it and are the most motivated to solve their problems now, not once the budget cycle gets around to funding a project. Central IT, where most EAs practice, is a knowledge store for designing enterprise-scale systems but is constrained in its ability to deliver.
I visited a client recently, a large company with global operations and a large application delivery organization. A senior VP in charge of a large part of that organization told me an interesting story about its experience with a change in the way it approaches EA over the past few years. In brief, he said:
“A few years ago our architects were mostly dispersed into various parts of the delivery organization; we didn’t have an EA group.
“Then we recognized that we needed an EA group to better manage our use of technology, so we pulled those people out of delivery and formed them into an EA group.
“Since then EA has spent a lot of time understanding our business, building capability maps, and focusing on a more strategic level.
“But now I’m hearing cries of anguish from the delivery teams that they don’t have enough direct engagement and support from the architects in their delivery efforts. The delivery teams are concerned that EA has moved too far away from the actual delivery of business value, that EAs are not helping enough, and that it’s harming the effectiveness of the delivery organization.”
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.
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.