8 dirty little secrets of Enterprise Architecture and Strategic IT Planning

When I looked at these 9 little secrets of CRM (http://www.cio.com/article/496616/The_Dirty_Little_Secrets_of_CRM) I could not resist drawing the parallels with Enterprise Architectre and Strategic IT Planning (SITP)

One reasons I like to draw analogies with CRM is that while most people now realise that CRM is an enterprise activity - once upon a time, and not that long ago, it was dealt with much as enterprise architect is dealt with today i.e. with lots of people holding their own siloed views of the data in whatever happened to suit them. So it useful to learn from a more mature discpline. Sadly many people still think they can get success through the isolated ivory tower work of a small set of architects (usually focused on modelling).

So here are the 8 dirty little secrets of Enterprise Architect and Strategic IT planning:

1. Scope of data and users is key - An SITP planning system without real users and real customer-facing data is just an empty shell. This means that mechanisms of gathering data from many systems and people is critical.

2. Widespread adoption is key - User adoption and percentage-of-business represented are the key metrics of an SITP system's success. The virtuous cycle in SITP systems: the more users adopt the system, the more data that will be entered. The more credible and meaningful the SITP data, the more valuable an asset it is for all users. The more valuable the asset, the easier it is to get more users leveraging, and contributing to, the system. Even if some users are spectacularly effective thanks to SITP usage, if you only have pockets of usage, most situations are not represented in the database. Broad usage is more valuable to overall collaboration, as compared to deep but spotty use of the system. This means that you must plan to have a large user base and user of many types (i.e. not just a small number of modelling users). This requires role based interfaces and sophisticated security and data administration.

3. Data quality needs to improved through adoption - You will discover data quality problems that are irritants to every user and poisonous to the system's overall credibility. Data quality needs to be attacked at three levels: clean data as it is being loaded, identify sources of data pollution and systematically correct them; You need self-healing data; Identify business processes that corrupt the semantics of SITP data. This means that you must have mechanism for managing policies associated with data, have data quality reporting and support ETL process that effectively transform data on loading

4. Integration is key - There's no such thing as a siloed SITP system. Any useful SITP system must give users access to data that's beyond the purview of the SITP database. So integration will be essential, and it won't be as easy or inexpensive as the initial SITP project. Integration almost always exposes data problems that were hidden or tolerable in siloed system operation. This means you need various mechanisms for integration e.g. ETL, APIs etc.

5. Improving touch point process and governance is critical - Most of the time, an "SITP problem" is really a disjointed process, a policy conflict, or goofed data. Sometimes, a SITP system is just inadequate to the task - and you really do have a "SITP problem." But the most visible and important SITP problems are the ones resulting from holes or redundancies in business processes, contradictory business polices or rules, or hopelessly polluted data. You'll need to solve these other problems to have a chance of SITP success. This is why an SITP methodology that address touch point processes is critical.

6. Better performance is the goal (through transformation and optimisation) - The benefits of SITP really come from improvements to process enabled by, and in conjunction with, the system -- not from the SITP system itself. The twin purposes of SITP are to: enterprise intelligence (what they do and how they do it) to improve your ability to profitably operate. While SITP functionality plays a roll in achieving both these purposes, it's really about enabling your people to see better and react sooner. If you don't change your business processes to take advantage of SITP, your workers will just be doing dumb things faster and with less waste. Said another way, you'll probably need to change some processes and business rules to leverage SITP for maximum advantage. This is why we need to focus implementations around desired business outcomes and resulting (not in abstract framework or methods) and recognise that we need to change how things are actually done (and often by whom).

7. Sponsorship at the right level is key - Making a SITP system truly successful is a highly political act. Any time business processes, policies, and rules get changed, somebody's job, objectives, and even budget may change as well. This means politics at every level, and change management will be important for worker-bees ("will my job be automated?") and executives ("will my metrics and bonus change?") alike. If for no other reason than this, we recommend a phased, incremental approach to SITP deployment and expansion. This is why we recommend a phased, incremental approach (based on a CMMI model that make progressive improvements across the enterprise)

8. Incremental and progressive adoption is only practical approach - The benefits of SITP grow with the more users you have -- but you can never afford to bring everyone on the system at once. Even if system extension, integration, and data quality issues weren't relevant, even if you had perfect execution of a "big bang" system deployment, and even if you had the budget for all the user licenses on day one, you shouldn't do things that way. There are too many process issues to discover, too many political speed-bumps. Since leveraging SITP is a multi-year process, you need to plan for it that way. This is why each phase is carefully scoped.

Sadly what one hears from these people is: "I don't see how adopting SITP would help me with having conversations with my business stakeholders" - they seem to fail to recognise that it is not about "me", and "my conversations" or "my stakeholders" - it is about how the enterprise communicates as a whole. Once one would have heard this same kind solipsism from the sales team, the customer service team etc. regarding "I don't see how adopting CRM would help me with having conversations with my customers" now at least with CRM people recognise the enterprise nature of the activities and data.

See also http://enterprisesto.blogspot.com/2009/03/i-will-be-your-crmist-and-he-will-be.html