At the upcoming IT Forum in Las Vegas (May 26-28), I will be collaborating with Bill Band on a piece around using the customer experience to drive breakthrough process improvement, and with it, business performance. When you think about it, satisfying the needs of customers is what all business is about (OK you could argue that governmental organizations don’t have customers, they deal with the needs of citizens, but you get my drift).
In the first part of our presentation we will present research to support the view that improving the outcomes delivered to customers adds dollars to the bottom line of the business. Then I will switch to a theme dear to my heart -- that Business Process is at the heart of all significant Customer Experience efforts. And that comes down to:
How We Do What We Do -- Of course, the relationship between the Customer Experience, and how you do things, is pretty clear. I put this in the category of “Doing Things Right” -- i.e., the way in which the processes of the firm work and the employee behaviors.
What We Do -- But in order to deliver compelling customer outcomes, it’s also a question of “Doing The Right Things.” Which is about the business offering -- the services of the organization and the components that make it up. The business capabilities are, of course, a better way of thinking about this rather than the org chart (which is what so many folks seem to do ... decomposition of the org chart as a way of understanding processes).
Why We Do It -- And then it comes back to why we do this, and how it implements organizational strategy and the impact/benefit to the overall brand.
Ask people what makes May a noteworthy month, and many folks in the northern hemisphere will wax rhapsodic about its being the peak of springtime. Others might mention Mothers' day. Ask Forrester's IT analysts and they're pretty sure to immediately blurt out "IT Forum!" IT Forum -- the conference formerly known as GigaWorld -- is our biggest IT conference as it brings together all our IT analysts and about a zillion of our customers in all the IT-based roles for whom we do research. Each major IT role gets a separate track of research -- that's 10 tracks this year. It's essentially a week of non-stop analyst-attendee interaction in various forms. It's intense for both analysts and attendees and easily the most stimulating week on my calendar. At least, on my business calendar (wouldn't want you to think I don't have a life!).
Business-IT alignment is one of those persistent "Top 3" CIO issues. It has been this way just about as long as I’ve been in IT. You would think this would have been solved by now. After all, you put in business-driven IT governance, relationship managers, and some really nice dashboard, and you’ve covered about 90% of the advice out there. I’m going to suggest that business-IT alignment is being held hostage by complexity. Not technology complexity, since business leaders seem to be coming to terms with that. And not the mind-numbing spaghetti charts that show how complex our application and infrastructure landscapes are. They don’t understand these charts, but since we don’t understand them either, we can hardly expect business execs to. The complexity I’m referring to lies between their goals and the "stuff" IT delivers. They don’t see the connection. And since we see business execs having lots of goals, which shift over time, and strategies that also shift, we can’t show the connection. Instead, we say, "This is what you asked for, and this is what we delivered."
I'll admit to spending only 3 hours on the show floor. Most was spent in the cavernous and gloomy AIIM sessions area where I gave an "Analyst Take" session on SharePoint 2010, a talk on Dynamic Case Management, and reviewed suppliers for Document output for Customer Communications. My impression of the floor activity was an improvement over the last two years. Perhaps contraction of sponsorships had hit the right balance with demand, or perhaps the great spring weather and improving economy were at work, but the mood was upbeat and the crowds were steady. Vendors were grumbling less. Cloud talk and SaaS were under-represented. E-discovery and records management were in line. And the usual interesting collection of arcane conversion, migration, capture, and other providers - usually in the lower rent districts - continued the tradition. SharePoint was again pervasive. Those that say "that ship has come in" may not be aware of other ports and forms of transportation. One wonders what the future of the show is if the SharePoint sessions are the biggest draw and Microsoft and key partners have the biggest booths. Philly is a city that has lost its major corporate headquarters and no longer has growth industries - but it does not deserve its reputation. The AIIM show - with roots in microfilm and paper - is similar - and likewise - is still pretty good.
Starting a business architecture initiative with the goal of creating business architecture is the surest path to failure. Before you take your first step into business architecture, think long and hard about your goals, what value you are trying to create for the company, and your current ability to execute. The successful business architects I work with have a crystal clear view of the problems they are attempting to solve and the primary stakeholders for that problem set. They typically start with a narrow focus on a specific business problem and widen their approach as they make progress. While the more theoretical architects out there make strong arguments about what business architecture “should be” - the reality seems to be quite different. Business architecture success is creating an architecture that works – not one that adheres to an idealized business architecture model.
Forrester has identified seven business architecture goals along with their primary stakeholder. Business architecture practices can attack multiple goals simultaneously, but keep in mind that a narrower focus leads to faster value delivery.
This week, I talked with an IT group that had an organizational unit called “IT Business Management” with the charter to help IT run like a business. Well, it’s about time! I know a lot of IT strategists and consultants push the idea that IT should be an integral part of the business and shouldn’t be thought of as an independent organization. And that may be what it should be, but it’s not what it is today. Today’s IT is by and large a separate organization even when it is distributed across multiple business units.
In many companies IT is a large, complex business unit in its own right with a significant chunk of the business’s operating budget. When CIOs control hundreds of millions of their company’s dollars, shouldn’t they be thinking about what business value they are delivering on that capital? And isn’t a great way to do that by looking at and managing IT like a business?
When I first started talking about building a capability model for IT, I received a lot of blank stares and comments like: “Why would anyone want to do that?” My question is: ”Why wouldn’t everyone want to do that?” IT execs spend a significant portion of their time managing business demand to fit current IT resources but very little time improving IT’s ability to respond to increasing business demand. An IT capability model provides an excellent starting place to view IT like a business and identify what is most important to IT’s success and where to invest the few dollars we have to make it better. Many architects I talk with are having real success with business executives using capability maps to focus the conversation and their attention on what parts of the business are most important. With an IT capability map, we can do the same thing for IT.
A basic question we're frequently asked is: What is the difference between architecting and designing or, alternately, between architecture and engineering? Most people who ask this question have conflict in their organizations regarding which IT role does what, and it often comes down to which project artifact is whose responsibility.
For most organizations, the ambiguity between the responsibilities of the project-related architect (which Forrester refers to as a “solution architect” -- see Leverage Solution Architects To Drive EA Results) and a senior engineer is largely an academic issue. For most organizations what matters most is identifying and sourcing the individuals with the appropriate knowledge and skills and making them available to mission-critical projects. The availability of senior technicians on the projects is what often determines the level of detail in the design supplied by the solution architect.
The exceptions to the “most organizations” mentioned in above are the large-to-very-large engineering shops, such as the largestUS federal government civilian and DoD agencies, and large private sector organizations that do major engineering projects such as Boeing. Organizations that have over 1000 individuals in the development environment and launch multi-year $100M+ IT projects have closely defined project roles and do what is necessary -- including extensive external contracting -- to source the appropriately skilled individuals. In these environments the “it depends” argument is not sufficient and a clean delineation of role tasks and deliverables becomes necessary.
Business first!Whether your goal is business transformation, IT effectiveness, or just a better technical architecture, you need to start with a business-only view of your business architecture. If not, you will struggle with getting business sponsorship, and just as importantly, you will struggle with your own understanding of the business.
Until EAs convince business people that they do in fact understand the business, business leaders aren’t going to get excited about business architecture. This is basic sales 101- first understand the customer. To be sure, business cares about technology. In fact, they care about it quite a bit. Business leaders clearly understand how important technology is to their business success. What they are not so sure about is if IT understands the business. If the business was confident IT understood them well then we wouldn’t be seeing all the issues resulting from business people engaging with technology vendors and making technology decisions without IT’s input. Instead, they would be saying: “IT knows what I need, go talk with them.”
Architects that don’t collaborate with their business compatriots when building business architecture are finding it difficult to connect with the business. I have been talking with a number of architects lately that are getting push back from the business. What is the business saying? “That’s an IT thing.” Why are they saying that? Most likely because it is an IT thing - an IT centric business architecture.
It was quite a challenge to nail down all the detailed points ... and of course, the publishing process took a little getting used to. To be honest, I had most of it finalized over a month ago.
The next doc is just about to go into the editing queue - that will focus on the rationale behind the Pega acquisition of Chordiant, highlighting a major shift we see in the way that Enterprise Apps are developed.