I recently had a client ask about MDM measurement for their customer master. In many cases, the discussions I have about measurement is how to show that MDM has "solved world hunger" for the organization. In fact, a lot of the research and content out there focused on just that. Great to create a business case for investment. Not so good in helping with the daily management of master data and data governance. This client question is more practical, touching upon:
what about the data do you measure?
how do you calculate?
how frequently do you report and show trends?
how do you link the calculation to something the business understands?
It seems to be popular these days amongst industry pundits to recommend that organizations add a new Cxx role: the Chief Data Officer (CDO). The arguments in favor of this move are exactly what you'd think: the rapidly accelerating importance of information in the enterprise, and, as important, the heightened perception of the importance of information by business executives. The attention on information comes from all the rich new data that simply didn't exist before: sensor data from the Internet Of Things, social media, process data -- really just the enormous volume of data resulting from the digitization of everything. Add to all that: new technology to handle big data in a reasonable time frame, user-friendly mobile computing in the form of tablets, data virtualization software and data warehouse appliances that significantly accelerate the process of getting at the information for analysis, and the promise of predictive analytics, and there's plenty of cause for an information management rennaisance out there. With a little luck, the activity it catalyzes will also improve enterprises' ability to manage the data and content that's not so new but also very important that we've been struggling with for the last decade or so.
The only argument against creating this role that I've run across is that if CIOs and CTOs did their jobs right, we wouldn't need this new role. That's pretty feeble since we're not just talking about IT's history of relative ineffectiveness in managing information outside of application silos (and don't get me started about content management) -- we're adding to that a significant increase in the value of information and a significant increase in the amount of available information. And then there's the fact that the data could be in the cloud and not managed by IT, and there's also a changing picture regarding risk that suggests a new approach.
EA organizations are under increasing pressure to contribute tangibly to business results and to differentiate in greater terms than architectural domain skills alone. At the same time, compressed business cycles compel organizations to respond to events or opportunities at a more rapid pace. This often means resourcing and organizing into effective teams and projects quickly. EAs are often involved in multiple projects and teams and expected to have sufficiently broad experience, combined with multiple competencies to contribute to organizations’ responses. Many EA organizations see this skills tension increasing and often struggle to sufficiently develop or resource teams for the ever growing number and diversity of issues they are involved in. Increasingly, the contextual application of EA to real organizational issues and new opportunities is overtaking the traditional role of EAs in many businesses. For many EA teams and their stakeholders, the way in which value is derived from investments in EA is through increased contextualization and enhanced adaptability.
Shared services is widely employed in many industry sectors and is gaining increasing traction as organizations, particularly those subject to continuing cost pressures look for ways to control costs. For example, in December 2012 the UK government set out its next generation shared services strategy to enable savings of £400-600m per year. Shared services take many forms, but regardless of the type of shared service, when properly executed it can deliver a range of benefits. Benefits can result from economies of scale or scope, the ability to negotiate from a stronger consolidated base and through adoption of streamlined, common business processes. A shared services model can also enable groups to share knowledge and best practice as well as the services themselves. However, these benefits must be balanced with the flexibility clients (internal or external) require.
Shareable services typically include corporate service processes such as HR, procurement and finance and accounting. Sharing of enabling capabilities typically include IT infrastructure, workflow, data repositories as well as domain-specific expertise and resources. Viewed as business services, they can be defined in terms of outcomes and external dependencies using a combination of deliverables, processes, roles, and skills. This way EAs can help position the shared services within the organization’s architectural construct in terms of service provision to other functions within the business or to external partners or customers.
I just came back from a Product Information Management (PIM) event this week had had a lot of discussions about how to evaluate vendors and their solutions. I also get a lot of inquiries on vendor selection and while a lot of the questions center around the functionality itself, how to evaluate is also a key point of discussion. What peaked my interest on this subject is that IT and the Business have very different objectives in selecting a solution for MDM, PIM, and data quality. In fact, it can often get contentious when IT and the Business don't agree on the best solution.
General steps to purchase a solution seem pretty consistent: create a short list based on the Forrester Wave and research, conduct an RFI, narrow down to 2-3 vendors for an RFP, make a decision. But, the devil seems to be in the details.
Is a proof of concept required?
How do you make a decision when vendors solutions appear the same? Are they really the same?
How do you put pricing into context? Is lowest really better?
What is required to know before engaging with vendors to identify fit and differentiation?
When does meeting business objectives win out over fit in IT skills and platform consistency?
The pace of technology-fueled business innovation is accelerating, and enterprise architects can take a leading role by helping their firms identify opportunities for shrewd investment. In our 2012 global state of EA online survey, we asked again what the most disruptive technologies would be; here’s what we found:
The results shouldn’t surprise anybody; however, if you are only looking at these, you are likely to get smacked in the face when you blink -- things are changing that fast. In the near future, new platforms built on today’s hot technologies will create more disruption. For example, by 2016 there will be 760 million tablets in use and almost one-third will be sold to business. Forrester currently has a rich body of research on mobility and other hot technologies, such as Forrester’s mobile eBusiness playbook and the CIO’s mobile engagement playbook. But by 2018, mobile will be the norm, so then what?
There are interesting debates all around the globe about whether there is the need for a next gen EA framework. James Lapalme recently published an excellent article: Three Schools of Thought on Enterprise Architecture explaining the reasons of such debates.
In this article James identifies three schools of thoughts for EA, each with their own scope and purpose:
"Enterprise IT architecting" which addresses enterprisewide IT, and the alignment of IT with business.
"Enterprise integrating" which addresses the coherency of the enterprise as a system with IT is only one component of the enterprise.
"Enterprise Ecological Adaptation" which addresses the enterprise in its larger environment
As businesses get larger, and the need for effective alignment of the business with technology capabilities grows, enterprise architecture becomes an essential competency. But in China, many CIOs are struggling with setting up a high-performance enterprise architecture program to support their business strategies in a disruptive market landscape. This seems equally true for state-owned enterprises (SOEs) and multinational companies (MNCs).
To gain a better understanding of the problem, I had an interesting conversation with Le Yao, general secretary of Center for Informatization and Information Management (CIIM) and director of the CIO program at Peking University. Le Yao is one of the first pioneers introducing The Open Group Architecture Framework (TOGAF) into China to help address the above challenges. I believe that the five-year journey of TOGAF in China is just an early beginning for EA, and companies in the China market need relevant EA insights to help them support their business:
Taking an EA course is one thing; practicing EA is something else. Companies taking TOGAF courses in China seem to be aiming more at sales enablement than practicing EA internally. MNCs like IBM, Accenture, and HP are more likely to try to infuse the essence of the methodology into their PowerPoint slides for marketing and/or bidding purposes; IBM has also invited channel partners such as Neusoft, Digital China, CS&S, and Asiainfo to take the training.
TOGAF is too high-level to be relevant. End user trainees learning the enterprise architecture framework that Yao’s team introduced in China in 2007 found it to be too high-level and conceptual. Also, the trainers only went through what was written in the textbook without using industry-specific cases or practice-related information — making the training less relevant and difficult to apply.
The rise of bring-your-own-device (BYOD) programs in organizations is well documented and it is a growing trend that shows few signs of slowing down. The benefits in increased worker flexibility and improved modernity of the working environment can often outweigh the various and well documented technical, legal and operational concerns. The architectural implications are equally important and often less well understood. The architectural view on BYOD can take multiple perspectives, for example: a device view, a centralized infrastructure view or a usage focused view. Common components such as support, management and security apply all of these architectural views. Each view provides a discrete perspective of the architectural patterns required to successfully architect for BYOD. The selection of the right view for your organization depends largely on the organizational environment in which it will be employed. Irrespective of the view employed, key to architectural success with BYOD programs is to identify and plan for critical aspects of a BYOD scenario based on the different architectural views.