Why Most Organizations need a Data Strategy

One of the most important tasks that a Data Architect is often asked to help with is the creation of an Enterprise Data Strategy. But why is Data Strategy so important and what exactly does it consist of, and lastly why is this a task that a Data Architect should be leading or supporting?

So, what is a Data Strategy? Let's review what it isn't first…

• A Data Strategy is not a list of generic principles or obvious statements (such as "Data is an Enterprise Asset")
• A Data Strategy is not merely a laundry list of technology trends that might somehow influence the organization in coming years
• A Data Strategy is not a vague list of objectives without a clear guiding vision or path for actualization.
• A Data Strategy is not merely the top level vision either, it can expand into critical data domains such as Business Intelligence and eventually represent a family of strategies.

Now we will attempt to define what an Enterprise Data Strategy really is:

Enterprise Data Strategy is the comprehensive vision and actionable foundation for an organization's ability to harness data-related or data-dependent capability. It also represents the umbrella for all derived domain-specific strategies, such as Master Data Management, Business Intelligence, Big Data and so forth.

The Enterprise Data Strategy is:

• Actionable
• Relevant (e.g. contextual to the organization, not generic)
• Evolutionary (e.g. it is expected to change on a regular basis)
• Connected / Integrated - with everything that comes after it or from it

This definition helps to understand what Data Strategy is; so now we need to understand why most organizations need one. Here are a few of the reasons why…

1. Without a centralized vision and foundation, different parts of the enterprise will view data-related capabilities differently. This inevitably leads to duplication of both data and data systems across the organization and thus makes it quite difficult to determine the 'truth' of one's data and will also drive up costs.
2. The Data Strategy provides the basis for all enterprise planning efforts connected to data-related capability.
3. The Data Strategy is the tool that allows for unification of Business and IT expectations for all enterprise data-related capabilities. The more detailed and comprehensive it is, the better the chance that both sides will fully understand each other.
4. There is no better place to define the metrics or service level expectations that should apply across the enterprise.
5. This is the best place to explain thoroughly how management of enterprise data can be leveraged to support organizational mission objectives or processes.

A Typical Enterprise Data Strategy includes the following components:

• A definition of what types of data or information needs to managed from an enterprise perspective (and yes this ought to be fairly specific).
• A determination in regards to roles (organizational) in terms of who owns what data or data systems.
• A mission statement in relation to exploitation of data assets. So, we've taken for granted here that these are enterprise assets - what's important is understanding how they ought to be used.
• Initial or top level expectations for enterprise-wide service level metrics (for data systems and data quality).
• Introductory versions of all domain-level or specific sub-strategies, such as; Information/Data Governance, EDW, MDM, Content Management, Big Data etc.
• Top level planning decisions or expectations for making those designs.
• Identification of key enterprise challenges and anticipated design decisions.

Now we're ready to address why Data Architects are typically involved in creating and executing Enterprise Data Strategy. Data Architects are specialists within the larger field of IT Architecture, while some have wider architecture experience - others do nothing but work with data and data systems. Data Architects make good candidates for helping to craft Enterprise Data Strategy because they are typically charged with defining all existing and future data related systems capability. Architects often also have a good deal of experience working directly with business stakeholders and thus help to ensure both business and IT perspectives are taken into consideration while crafting the Data Strategy.

There are in fact few other roles qualified to lead this type of an effort. While CTO, CIO or CDO’s (Chief Data Officer) might quality to lead such a task, often times they are stretched too thin to focus on building the comprehensive Strategies necessary to make a real difference for the organization. The Data Architect can typically dedicate their full attention to this task and have the full support of all necessary resources (including the CXO level personnel) to ensure that the necessary analysis, negotiation and planning goes into the Data Strategy so it can be relevant and ultimately successfully.

copyright 2014, Stephen Lahanas

Read More

Creating Agile IT Transformation - part 1

IT Transformation has been a buzzword for more than a decade now, but what does it really mean? The first time I heard it used regularly was in relation to specific Department of Defense (DoD) technology initiatives from the early 2000's. I had the opportunity to work on several of those projects and as the years progressed the concept of IT Transformation evolved quite a bit – becoming much more flexible and yes – even somewhat Agile in nature.

At first IT Transformation was viewed from a more comprehensive perspective, sort of an organizational make-over if you will. This initial view involved Transformation at multiple levels and from multiple perspectives. This often included consolidation of organizational functions as well as IT systems and hosting capabilities – all at once. In some cases, IT Transformation was becoming almost synonymous with Enterprise Resource Planning (ERP) initiatives; in fact some people still view it that way.

A holistic perspective of IT Transformation

The problem with the comprehensive view of IT Transformation though is its scope. As hard as it is to even get a project like that off the ground (funding, stakeholder buy-in etc.) successfully executing something that large is even more challenging – sort of the ultimate “Big Bang” approach. Despite that, Transformations are still hard to avoid – organizations that don’t adjust to changing realities and emerging technologies can rapidly become ineffective or redundant.

So, how does one approach Transformation in a way that can actually succeed? First we need to redefine it:

IT Transformation

“The set of activities required for an organization or group of related organizations to successfully adopt emerging capabilities and practice. This emerging technology or practice could be focused on one major capability or may involve multiple technologies and processes associated with a specific initiative.”

This definition allows us to view Transformation differently. Rather than the entire organization changing all at once we’re focusing now on areas of specific significant change.  This Transformation based on significant enterprise change can be further decomposed into segments similar to the previous view of holistic Transformation (the business portion, the data portion, the solution portion etc.).

You might be asking yourself how this new view of Transformation differs from any other type of major IT initiative or project. The primary difference is that while today’s more Agile Transformation can be highly targeted it still exhibits these differentiating characteristics from typical IT projects:

1.  It is designed to fit into a larger set of Transformation goals (e.g. it comes pre-integrated, enterprise-aligned from day 1)
2.  It typically involves the combination of several distinct technologies and processes – moreso than other IT projects (because it is already enterprise or strategic-facing in nature)
3. It typically is more mission-focused than many other IT projects. In other words, it has been selected to tackle a critical business issue, not just a technical concern.

Solution providers that support this new type of Transformation are somewhat more flexible in their perspectives on how to tackle complex Transformations than some of the more well-established consulting firms may be. While an ERP transformation may easily cost several hundred million dollars and still not succeed, Agile Transformation approaches look for smaller chunks of capability with higher ROI and success rates.  We will highlight the primary Use Cases and several case studies for Agile Transformation in the near future.




copyright 2014, Stephen Lahanas

Read More

Making the Case for IT Architecture

There are still quite a few misconceptions in regards to IT Architecture. For many, hearing the term "Architecture" in relation to any IT topic seems to imply Enterprise Architecture (EA). To others, the notion of formal design processes represents the anti-thesis of Agile or responsive problem-solving. These misconceptions are unfortunate because there has never been more architecture connected to IT in actual practice and there has never been so much need for it.

So, let's start at the top - IT Architecture is a continuum and an umbrella for every design process in the enterprise. IT Architecture is the foundation for understanding every enterprise capability as well as being the starting point for all planning and governance. The reason it serves all these roles is because it provides the necessary insight for guiding all of those processes. Without that insight, making decisions and governing IT management or evolution becomes more or less like guesswork.

Why should this be so? Well, it has a lot to do with the disruptive and dynamic nature of Information Technology; it is not all uncommon for large organizations to have incomplete information in regards to their own systems, costs and data. Often times there are redundant, distributed islands of IT that cross business units or may even involve the separation of capability across IT & business communities. Gaining a complete picture of what's going in many organizations is quite a challenge - but is absolutely necessary in order to unify systems operation and to move forward in a coordinated fashion to exploit new opportunities and technologies.

So, let's go back and address those two very common misunderstandings again…

1 - IT Architecture and EA are the same thing (and EA is useless) - now I've paraphrased some of the criticism I've heard over the years about EA, but of course there is a legitimate question there. Is there any real value to EA? First off, EA and IT Architecture are not the same. EA is a top level architecture process and represents perhaps 20% of the total architecture that occurs in the typical enterprise. EA is integrated with IT Strategy and portfolio planning and governance.

Does EA have value? Yes, it does. It represents that portion of IT architecture that helps allow business stakeholders understand their IT capability landscape. It is high level enough to function as a communications tool, a governance framework and a project estimation bench-marking tool. EA is also, when done properly, the bridge to all other solution architecture.

2 - Does Architecture inhibit Agility? This is a thorny question and a complex topic, but I will try to address it briefly. At first blush, it might appear that any formalized design process might not fit within the context of the Agile Manifesto. But there are some important considerations worth noting that tend to contradict that initial assumption:

• Agile, as a methodology, has never been effectively transferred from a system or application scope to an enterprise scope except through the adoption of more iterative, time-boxed approaches to lifecycle management. There is a good reason for this - purist Agile approaches are focused on deriving requirements through experimentation rather than up front design.
• When you move from the application development scope to the enterprise integration domain things change - a lot. The problem at this level is no longer invention, but reconciliation and complexity management. In this context, the discovery associated with design relates to existing capability and introduction of well-defined new technologies. Here, IT Architecture provides the reference point for establishing and maintaining control over what otherwise might become a chaotic environment.
• Agile is all about making the application work by any means necessary - operations is all about making the enterprise work as a whole in the most efficient manner possible.
• And even within Agile, there is a design process and that process is merely one specifically-tailored component of a larger family of IT Architecture practice.

Perceptions are often hard to change and IT Architecture is a large, emerging and complicated field of practice. After working as an architect for 16 years, I can honestly say I've never seen more organizations doing architecture work. More often than not that architecture has become an important part of their overall IT management strategy. Yet, the continued misconceptions tend to hold back the true potential of IT Architecture. Too often, people view it from the perspective of one of the many sub-disciplines (such as Agile design, etc.) rather than seeing it as a holistic enterprise resource. I think that as the realization of its true scope becomes clearer IT Architecture will become even more important in the years to come.

copyright 2014, Stephen Lahanas

Read More