Lately, I have become a bit obsessed with evaluating the linkage between good process design and good experience design. This obsession was initially sparked by primary research I led earlier this year around reinventing andredesigning business processes for mobile. The mobile imperative is driving a laser focus for companies to create exceptional user experiences for their customers, employees, and partners. But this laser focus on exceptional design is not only reshaping the application development world. This drive for exceptional user experience is also radically changing the way companies approach business process design.

Over the past six months, I have run across more and more BPM teams where user experience is playing a much larger role in driving business process change. Some of these teams highlighted that they see experience design playing a greater role in driving process change than the actual process modeling and analysis aspects of process improvement.

Categories:

Insufficient flexibility for business customization, poor ease of use, and long implementation have become major complaints about SAP’s core products by many SAP clients in China. Despite SAP’s wide adoption by large enterprises in China, including Nongfu Spring (the first one in APAC using HANA — in-memory computing platform — in production) and Sinopec (ranked No. 5 in Fortune 500 in 2012), these client issues are problems for SAP for its continued expansion into the China market. SAP uses its SAP Labs network across the globe to deliver local market-oriented solutions for different geographies. In my recent visit to SAP Labs China, one of the four hub labs that drive corporate product strategy and execution of global projects, I found that SAP is taking the right steps to integrate local requirements and deliver product capabilities that address the above issues:

Solutions customized for China regulations and business practices. SAP Labs China developed not only localized solutions for general purpose such as Golden Tax features, which is mandated by the Chinese government for its interfacing national taxing system, but also key solutions for local industries such as business real estate, international commerce, public finance, and healthcare.

More ease of use. To solve the ease-of-use problem, including the user interface look and feel and usage behavior of the product, SAP Labs China reinvented finance user experience and business processes for Chinese customers, and it also optimized the user interface for its human resource module.

Categories:

The use of road maps to illustrate technology plans is fairly widespread. Whether it's a vendor explaining its product plans or a technology architect showing the evolution of a particular area of the infrastructure, road maps are great for communicating what happens when. And when plans as illustrated by the road map get sign-off, they can become a useful tool in change management as well. Someone wants your key resources for a special project? Fine, but all the dates on that road map they just approved just shifted six months to the right. Road maps tell the story of what to expect an organization to accomplish for the foreseeable future, and that's what makes them powerful.

That's why road maps that link traditionally difficult-to-explain areas of technology, such as those related to information management, to specific and highly desirable business outcomes can be a major win for architects looking to communicate what they're doing and why. There's always been a Catch-22 about explaining the value of complex technologies to audiences with no appetite for technical complexity -- but with needed sign-off authority for key resources (like funding). If the EA team has credibility (OK, that can be a big "if"), just showing the interrelationships between business outcomes, business capabilities, IT projects, and required activities in the various EA domains can satisfy the need for "explaining" that complex technology. Or for explaining the need for that not-well-understood architecture process that requires business involvement, such as information architecture development or governance.

I just finished analyzing our Q3 2012 Global State Of Enterprise Architecture Online Survey, where we asked a number of questions at the end of the survey on how firms identify and introduce new technology – new technology that your firm is counting on for innovation and competitive advantage. The results underscore a conviction that is growing in me: IT’s “one-size-fits-all” approach to standardizing everything and general aversion to risk isn't cutting the mustard. Simply put, opportunities for competitive advantage through technology-fueled disruption get missed, and this means digital extinction. Some data from our survey of 207 enterprise architects:

58% reported that sales and marketing is among the top five most likely organizations to deliver technology innovations, and they are chasing windows of opportunity that close in months. IT typically takes at least a year to do anything.

52% say there is at least some business dissatisfaction with the level of new technology introduction. The top reason, given by 78% of respondents, is that IT is too slow.

70% of respondents admit their firms have trouble reacting to disruptions caused by emerging technology, and 60% admit to difficulty reacting to change in general.

Over the last few months I have met or spoken to a significant number of Forrester clients who are undertaking a business architecture initiative. As you can imagine, these initiatives have various sponsors and are at various levels of maturity. Some business architecture (BA) initiatives are being driven by chief information officers (CIOs) and chief technology officers (CTOs) wanting to get a seat, and become an influencer, at the strategic decision-making table. Whilst others are being driven by business executives, who either believe business design and transformation is a business responsibility or that IT has insufficient business competency to understand and deliver what is required.

The different levels of maturity struck me, as just like the English Premier League (that’s where real football is played, for those not in the know) there are the elite (the big boys – top five or six teams) and there are the also-rans/others. There are also the elite BA teams and the non-elite BA teams. The gap between these two groups is growing, which will be a nightmare for a non-elite BA leader benchmarking his initiative against other organizations. Where one could argue in the football reference it is money that divides the two groups, as this attracts better players and creates better teams, with BA teams it appears to be more based on focus. Less mature and non-elite BA teams focus their efforts primarily on the building of BA, reacting to siloed demand and then selling or pushing BA artifacts to stakeholders in the hope that they find these artifacts useful. Whereas, the elite BA teams focus on addressing stakeholder needs and the use of BA, delivering relevant BA services and allowing stakeholders to pull the BA artifacts that address the challenges they face.

The number one reason I hear from IT organizations for why they want to embark on MDM is for consolidation or integration of systems. Then, the first question I get, how do they get buy-in from the business to pay for it?

My first reaction is to cringe because the implication is that MDM is a data integration tool and the value is the matching capabilities. While matching is a significant capability, MDM is not about creating a golden record or a single source of truth.

My next reaction is that IT missed the point that the business wants data to support a system of engagement. The value of MDM is to be able to model and render a domain to fit a system of engagement. Until you understand and align to that, your MDM effort will not support the business and you won’t get the funding. If you somehow do get the funding, you won’t be able to appropriately select the MDM tool that is right for the business need, thus wasting time, money, and resources.

Here is why I am not a fan of the “single source of truth” mantra. A person is not one-dimensional; they can be a parent, a friend, or a colleague, and each has different motivations and requirements depending on the environment. A product is as much about the physical aspect as it is about the pricing, message, and sales channel it is sold through. Or, it is also faceted by the fact that it is put together from various products and parts from partners. In no way is a master entity unique or has a consistency depending on what is important about the entity in a given situation. What MDM provides are definitions and instructions on the right data to use in the right engagement. Context is a key value of MDM.

Categories:

It is that dreaded time of year again where we have to report via the performance management system (PMS) on our individual performance and the value we bring to the organization. I say dreaded, because we all know that in reality the goals and objectives were set some time ago in the past, maybe a year ago, and a lot has happened since that time. The person you report to may have changed, you were redirected to other tasks, and so on. Everything seemed possible at the time of the objective setting, but now the reality hits that you were or may have been far too optimistic about your own capability. The self-assessment is difficult as you are not sure whether your manager has the same view as you. You believe you met the objective, but does their expectation meet your actual delivery? If a good performance relates to more money, the pressure and stress builds.

So whilst I was preparing for my Orlando Business Architecture Forum presentation I started to think about how business architecture teams measure and manage their performance. One of my next reports for Forrester’s business architecture playbook addresses BA performance. It was also a hot topic for the EA Council members in Orlando. I had a number of 1-on-1’s with clients who particularly asked about BA metrics and performance — in particular, “What do other business architecture teams do?”

I started listing the questions that, when answered by clients, would lead to a very valuable report for all BA leaders:

Do you measure your BA’s performance? Clients often advise me that they have fairly mature BA practices. However, very few can articulate how they measure their performance, and often comment that the business asks them to demonstrate how BA adds value. So, it would be useful to understand whether BA leaders measure their team’s performance and why they do or don’t.

Categories:

In Forrester’s EA Practice Playbook, we describe high-performance enterprise architecture programs as “business-focused, strategic, and pragmatic.” They are business-focused so that the direction and guidance EA provides has clear business relevance and value. They are strategic because the greatest value EA brings is to help its business to achieve its business strategies. They are pragmatic because, well, the path to strategy is never straight, and EA teams who aren’t agile in their approach get pushed aside.

National Grid, facing the enormous changes to the utility industry, developed an enterprisewide business capability model and made that the center of their joint business-IS planning. The result? All the way up to the C-level, EA is being recognized as a strategic change agent.

Scottish Widows Investment Partnership “reinvented” their EA program, centered on a business capability model developed over four weeks, and used to organize and link all the EA portfolios. They now have business managers as well as EA using their architecture planning tool.

Outside of BPM, one of my other passions is mentoring college students through the process of launching new startups. I enjoy helping students tighten up their business ideas and seeing them build business plans that can attract the funding they need to stand up and implement their ventures.

Recently, after reviewing and providing feedback on a student’s business plan, the student responded, “I can launch my business without a business plan; all this planning seems like a waste of time.” At first, I thought he was joking. However, I could read by the look on his face that he was serious. I am sure you can imagine the conversation that followed.

The next day when I reflected on the conversation, I had a moment of satori. I could see that startups share the same risk/reward profile as business process management initiatives. Just like startups, BPM initiatives promise huge returns to investors and stakeholders. Additionally, just like startups, BPM initiatives are fraught with risks such as inadequate funding, low adoption, and difficulty attracting skilled resources.

My conversation with the student about the importance of business planning seemed to parallel conversations I often have with enterprise architects and business architects launching or retooling their BPM initiatives. Most tend to overestimate the BPM’s potential rewards and downplay — or do not fully understand — the risks involved with launching a BPM initiative. However, for the most successful BPM initiatives, I have found that their leaders tend to have a “lean startup” mentality.

There was lots of feedback on the last blog (“Risk Data, Risky Business?”) that clearly indicates the divide between definitions in trust and quality. It is a great jumping off point for the next hot topic, data governance for big data.

The comment I hear most from clients, particularly when discussing big data, is, “Data governance inhibits agility.” Why be hindered by committees and bureaucracy when you want freedom to experiment and discover?

Current thinking: Data governance is freedom from risk.The stakes are high when it comes to data-intensive projects, and having the right alignment between IT and the business is crucial. Data governance has been the gold standard to establish the right roles, responsibilities, processes, and procedures to deliver trusted secure data. Success has been achieved through legislative means by enacting policies and procedures that reduce risk to the business from bad data and bad data management project implementation. Data governance was meant to keep bad things from happening.

Today’s data governance approach is important and certainly has a place in the new world of big data. When data enters the inner sanctum of an organization, management needs to be rigorous.

Yet, the challenge is that legislative data governance by nature is focused on risk avoidance. Often this model is still IT led. This holds progress back as the business may be at the table, but it isn’t bought in. This is evidenced by committee and project management style data governance programs focused on ownership, scope, and timelines. All this management and process takes time and stifles experimentation and growth.