Enterprise Strategic Transformation & Optimisation

Make good information available to everyone

2012-02-05T17:41:00.000-08:00

I like what Jeanne Ross (Director and Principal Research Scientist at MIT’s Center for Information System Research) says as reported here: http://www.zdnet.com/blog/gardner/enterprise-architects-play-key-role-in-transformation-data-analytics-value-but-they-need-to-act-fast-say-open-group-speakers/4489

Coming from the siloed past in IT, companies are now moving to business service-driven processes across various resources ... But they need to recognize the forces around consumption of such services, not just the implementation.

Making good data management a priority, a “single source of truth” is also at the heart of making EA valuable,...Ensuring the quality of data and the speed of data refresh will help enterprise architects rise in performance appreciation more than just about anything else..."

“You don’t get good analytics with bad data,” ...“The secret to good EA is to put information in every person’s hands so they can use data better.” And that in turn will help transform the business and spur added innovation using IT systems and good architecture principles.

Most senior executives aren’t very good at combining business and technology strategies

Principles and patterns

2012-01-30T18:54:00.000-08:00

I have looked at these "principles" for many years and it seems to me: firstly that they are effectively constraints (almost like goals, measures of success i.e. something to be achieved ideally) and that secondly they are often opposing constraints. So that what is required in design in an understand of the trade-offs. This turns out to be very complex if tackled from 1st principles so in mature disciplines the idea of patterns is used which effectively encapsulate a set of principles (and materials) to suggest how something can be achieved. I am not convinced that principles in their raw form can effectively be consumed and applied.

This comment was made in response to this: http://www.ebizq.net/blogs/ea_matters/2011/11/enterprise-architecture-principles-lets-talk-about-them.php#c19997

Counter-reductionist approach to requirements and projects

2012-01-26T12:16:00.000-08:00

I like what this man Dr. Leon Kappelman says "It is the bane of applications and data to be stovepiped and compartmentalized. But that remains the standard by which we train IT and business managers" (http://www.information-management.com/newsletters/data-architecture-quality-integration-UNT-Kappelman-10021830-1.html).

He came to EA the same way I came to EA ie.

"My original focus was software development and obviously the importance of getting the requirements right. Well, it turns out that to have the requirements right, you need what you are working on in the context of the whole because otherwise you might build a great system but it doesn't create value. It might be adding redundancy or be the 73rd system to connect 72 other systems. Even if those other 72 systems are part of stovepiped business units and are perfectly aligned with them and serve their needs, as a whole the enterprise is wasting a ton of money and a ton of resources and talent."

I think it great that he identifies the problems with the “reductionist” which I had put down to solipsism of many of the technical people I have met who are interested just in their little slice of reality - their jigsaw piece. The problems are not just with technologist, but with projects in large organizations, where most operate as if the project's by itself produces business value.

I think we need to look at solutions and methods to suppirt a counter-reductionist approach. That is why we have focused on a strategic holistic approach to demand and requirements management.

EA - leadership and discipline supporting a cultural shift

2012-01-12T13:02:00.000-08:00

MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation - http://www.zdnet.com/blog/gardner/mits-ross-on-how-enterprise-architecture-and-it-more-than-ever-lead-to-business-transformation/4463

What I like about this is the clear identification of the:

cultural shift that is required
need for understanding through the enterprise (not just with individuals) and the identifying the limitations of the "hero" model
need for discipline and the natural tension that needs to exist (Cf. the town planner vs the laisez faire property developer)
difficulty of getting good adoption of and need for persistent coaching and a clear vision
need to focus on pain points that the executive are focused on (not boiling the ocean)

Cultural shift

"... we’re learning about enterprise architecture is that there’s a cultural shift that takes place in an organization, ... and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline."

Enterprise, not just individuals using an heroic approach

"...What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best ...Nobody wants to get rid of the heroes ...What we’re trying to do is adopt a culture of discipline, where there are certain things that people throughout an enterprise understand are the way things need to be done, so that we actually can operate as an enterprise, not as individuals all trying to do the best thing based on our own experience."

Natural tension

"... the architect should be able to create a very constructive tension in the organization, and that’s the tension between individuality, innovation, local responsiveness, and the need for enterprise thinking, standardization, and discipline."

Focus on pain points

"... companies who were best at adopting architecture and implementing it effectively had cost pressures. What happens when you have cost pressures is that you’re forced to make tough decisions. ...If you have all the money in the world, you’re not forced to make tough decisions. "

"... The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time. ...They can already see the unfolding bigger picture, but there’s no management commitment yet. So they stick to the capabilities that they are confident the organization will use. That’s the way they get the momentum to build. That is more art than science and it really distinguishes the most successful architects."

Getting adoption requires persistent coaching

While the following comments are not directed at EAMS solutions I think them apropos

"... You build something that’s phenomenally good and appropriate for the business and then you just assume, that if you give them a little training, they’ll use it well. "

" ...That’s actually been a remarkable struggle for organizations. ..."

" ...there aren’t very many companies that have come anywhere close to leveraging their platforms the way they might have imagined ..."

" ... It’s harder than we thought. It requires persistent coaching. It’s not about training, but persistent coaching. It requires enormous clarity of what the organization is trying to do, and organizations change fast. Clarity is a lot harder to achieve than we think it ought to be."

When will we learn that heroic individualism is not enough

In an presentation to EA many years ago I quoted a third party who had suggested some of the the goals were: containing costs and risks, be timely, being more adaptable and customizable and the challenges included managing complexity (which requires some discipline and semantic precision) and failing methods “Today, the most common model … is based on an approach that we call ‘heroic’ ”. Some of the suggestion made at the time were: context maps for cataloging assets and knowledge; clear methods for making decisions; patterns, business/industry reference models, default infrastructural templates or frameworks; and focusing on component topologies and interactions.

This source for this is not recent - it is an old IBM Systems Journal item in 1999 discussing architecture.

Summary

I have written elsewhere on strategies for dealing with complexity (the key being semantic precision), industry reference models and patterns (which encapsulate principles, preferred technologies, standard component topologies and interactions). This item from Ross is great in identifying some of keys to successful implementation: clear vision and persistent coaching, discipline, enterprise wide approach etc.

A Copernican shift in Enterprise Architecture

2011-12-23T12:22:00.000-08:00

This (Copernican shift) discusses a shift of centricity- for EA - from techno-centric to business-centric. I think it identifies some good points (see quotes extracted in italic below).

"... EA is becoming a thing that companies do, not a team they have"

We need to focus on how the enterprise gathers, manages and utilises the knowledge.

" ... the focus or central outcome is not technology success; it’s business success. ..."

We need to see how initiatives are driven by the business architecture and realise that ALL requirements (demand) must be driven by the business plan and architecture. Their are no technical requirements.

" ...This has profound implications for the skills and techniques that EAs need for the future. ..."

Items that discuss this further: EA solipsists ; I will be you CRMist ; EA can't be done by Enterprise Architects.

We need EA's to stop thinking their are going to engage the business with UML, ER diagrams, and other technical arcana (see UML no good for EA). We need EA who are articulate and natural communicators, collaborative and including (rather than doing pictures and models for their own or other EA's edification). See Communicating in languages the business understands

"... Integration takes on a broader context that includes people integration, process integration, and traditional technology integration. ..."

This is why in a taxomomy for EA we need to recognise as communications as key aspect of any EA "framework". Old "frameworks" (i.e. with rows and columns) - had columns for things like: what (knowledge, information, data etc.), how (function, process etc.), but lacked a natural column for communication - which ultimately drives the need for all interfaces (with people, with systems).

"... most successful firms will be “architecting their businesses for success …"
"… already seeing firms eschew the term “EA” as being to laden with techno-baggage. …"

Way back in 2007 - the need to use different terms was discussed here: Business and IT Transformation.

"Why Bad Things Happen"

2011-11-30T16:42:00.001-08:00

"Why Bad Things Happen To Good Organisations: Part 1" - Jonathon Kendall is a very interesting.

Based on a study of public sector projects:
- only 44% of spend on capital projects is inefficient, with 31% completely lost
- only 13% of programs met more than 65% of targeted objectives.
- only 59% of $100m+ programs longer than 5 years were delivered; 60% of those delivered were de-scoped or fragmented into other programs, and 22% were not delivered at all – none were delivered as per the original specification.
- 87% of IT programs go beyond schedule and budget, with an average overrun of 52%.
- 99% of all +$100m/5 years projects were significantly de-scoped, re-dimensioned or re-focused
- 2.25% is the average return of Corporate Service programs (they have worst return but made up over half of all capital projects undertaken.

They identify these factors embedding inefficiency:
- Lack of measurable, outcome-oriented performance metrics and reviews.
- Actual deliverables are not measured against promised or projected deliverables.
- Deliverables are not clearly articulated, defined or documented.
- Gross over-estimation of program benefits compounded by gross underestimation of capital costs and risks.
- Zero incentive for improved delivery performance.

They recommend:
- Outsource Delivery Management
- Outsource Commoditised Services.
- Divest Commoditised IT Services, Invest In Specialised IT Services.
- Adjusted Benefits & Costs (to be realistic)
- Reduce Program Delivery Intervals.
- Re-orient All Program Deliverables To Service Outcomes. "All capital works programs deliverables should be intimately equated with policy, legal, regulatory or directed outcomes."

A better approach to Requirements management - where the Requirements are directly expressed in terms of: policies, outcomes, KPIs and the capabilities and behaviour of the organization is in practice critical to many of the recommendations. It allows you define in a common way the business requirements to be met by all outsourcing (delivery, commoditised services); clearly define specialised services (based on the specialised aspects of the business architecture)

Strategic Requirements management

2011-10-11T18:03:00.000-07:00

Semantic precision has a brand new solution to this requirements management challenge based on an approach to business requirements, that leverages off a business architecture framework and is built on a business transformation management platform. See: www.semanticprecision.com

I think this item is excellent "Why is IT Project Failure Always an Option" http://java.sys-con.com/node/2007687 - extracts below

If the requirements in a single project are incorrect the outcome from that project is unlikely to be correct. But even if the requirements in a project are correct if the requirements across the set of projects that transform the enterprise are not correct (consistent, coherent etc. as a set) the net business transfromation result of all the projects across the enterprise is unlikely to be achieved.

I like the item below it makes the case that:

- project failure rates are high and unnecessary

- if you are not dealing with better approaches to requirements you're part of the problem

- a strategic view of requirements involves a direct connection between customer needs, IT spend, and strategic initiatives.

- maturity models are requirements

- an organization should be able to understands the strategic value of every project and be able to make daily decisions based on those values.

Extracts from the source below

"You [would] think that we'd be tired of the horrifying rates of failure, and the crushing consequences of those

failures ...

But if you are not spending more time understanding your customers - and developing tightly scoped

requirements to make great software to meet their real needs, not some imagined "needs mash-up" cobbled

together by the squeakiest wheels in your organization - you're part of the problem, and you're

accepting failure as an ever-present option.

It's time to stop the madness,... waste, ...cost overruns inpart from "inadequate requirements

management. ...

Most IT executives are familiar with the data on project risks, including overages and failure to meet

business needs. The risk described by Bent Flyvbjerg and Alexander Budzierin the September Harvard Business Review is that one out of six IT projects incurs "a cost overrun of 200%, on average, and a schedule overrun of almost 70% ...

It's time to get smarter ... and one way to do this it to take a strategic view of

requirements. A strategic view of requirements is not merely concerned with improving requirements or

improving projects; it incorporates a direct connection between customer needs, IT spend, and strategic

initiatives. It's requirements for grown-ups, and it involves maturing requirements.

The maturity model isn't just for app dev - it's for requirements as well. While most organizations

follow an ad hoc methodology for portfolio management and controlling project scope, a "requirements

mature" organization will find that all of IT understands the strategic value of every project (which

means that IT is aligned with internal AND external customers) and can make daily decisions based on

those values.

So, just what might this maturity process look like? It might look like a Requirements Center of Excellence. Here's one model for the increasing stages of maturity:

Stage 0: Ad Hoc. There is no requirements maturity. Requirements are created ad hoc, project scope is

based on "squeaky wheel"direction. ...

Stage 1: Individual. Although individual efforts may align with business strategy, there is no

consistent measurement of business return.

Stage 2: Team. Teams now share an understanding of business objectives; some individuals may share an

awareness of strategy. While individual projects may be measured for return, there is no organization-

wide validation of project return yet.

Stage 3: Business Unit. There is strong portfolio management across multiple teams. Teams and finance

consistently define and evaluate the project return across the portfolio. More than one business unit

may be at this level of maturity.

Stage 4: Organization. Throughout the organization, there is strong portfolio management based on

organizational strategy. The scope of projects is aligned with the strategy, and the entire portfolio is

regularly analyzed for business return.

... By making requirements strategic and by incorporating business strategy into requirements, not only will requirements mature faster, but those more mature requirements processes will lead to consistent business benefits.Which means great customer experiences, which come from great software.

EA Challenges - based on EA Excellence winners

2011-09-19T18:52:00.000-07:00

This looks at some common challenges identified in: http://m.infoworld.com/d/enterprise-architecture/the-2011-enterprise-architecture-awards-173372?page=0,0

My summary of common challenges:

building strong collaboration with business owners and IT to enable change scenarios to be explored – so reports and visualizations (suited to the various audiences) directly generated from the portal are key.
adopting approaches – so senior management commitment was required to make the necessary process, role and cultural changes.
unifying the architects: into a single, cohesive community using a common repository
data quality and management - enabling any authorized user to update information, and as they go about their usual work, without need for training or modelling. So you can avoid collection, and survey exercises or bottlenecks through a modelling function/tool.

General

To be effective change agents, enterprise architects must possess a deep understanding of business process, and grasp both the potential and the practical limits of new technology solutions. Despite their crucial role and unique combination of skills, enterprise architects seldom get the recognition they deserve.

Bayer Healthcare

The biggest challenge was data input and management. In the past, data had been collected using surveys sent to various regions, which were difficult to reconcile and keep current.

Of particular importance was building strong collaboration tools, so business owners and IT could more easily share and discuss change scenarios. To facilitate this, reports and visualizations can be generated directly from the portal.

Singapore Ministry of Education
Because EA is a relatively new discipline, significant senior management commitment was required to make the necessary process, role and cultural changes.

USAA
The most difficult challenge has been helping the organization, particularly its business partners, to recognize the value of the approach. "Few organizations are ready to accept a unified architecture. It's a long road to educate the players and it needs to be done through grassroots efforts, finding champions and showing success through pilot projects that deliver value."

Another challenge has been unifying the architects themselves into a single, cohesive community and creating a metamodel and deliverables that all disciplines can agree to and benefit from. USAA is building a common repository, which will have joint ownership across disciplines and its own governance team made up of representatives from the architecture community.

EA Excellence Awards

2011-09-19T15:56:00.000-07:00

I am often asked about examples of best practice. The following is an extract from: http://m.infoworld.com/d/enterprise-architecture/the-2011-enterprise-architecture-awards-173372?page=0,0 . Any comments I have made are in [ ...]

My summary

Each organization will take different path (based on their issues and priorities) - but some common themes emerge e.g.

single road map: bringing together people, process, technology, information
different perspectives: business, technology, and financial
knowledge bridge between business operations and IT: supporting collaboration between enable enterprise transformation.
online portal available to all: IT and business managers across the enterprise
all architectural disciplines represented: business architecture, information architecture, application architecture, integration architecture, infrastructure architecture, change management, organizational design, etc.
promoting standardization, simplication and management: applications, technologies, services, portfolios, transformation programmes
visualizations is key: heatmaps, roadmaps, capability maps etc.
scope is broad: business (business goals, capabilities), application and integration (application, SOA, interfaces, platforms/products), information (master data management, BI/data warehousen), infrastructure (data center, private cloud, provisioning).

We also note that leading adopters are looking at how to define their projects (requirements and solution elements) in the context provided by a holistic view of the enterprise.

Details follow

EA serves two main purposes: to provide a framework for collaboration between business and IT and to offer a pivot point for transformational change.

General

Each took a different path … [This is very important to realise. That is that each organization's approach to adoption may vary i.e. they may start solving the jigsaw puzzle from a different starting point – knowing that all pieces are there for a complete solution. Sadly some people just on piece of the puzzle and end up create a set of silos – and then repeat that pattern by create a different set of silos – without ever grasping that what is need eventually is a holistic view that runs across the top of all the business transformation areas]

American Express
... undergoing a major transformation. ...complexity of new product and service delivery channels, as well as the need for greater agility and shorter time to market ...

EA practice was charged with helping the company deliver a consistent, global, integrated customer experience based on converged services that run on a common application platform.

The EA practice has [delivers] reference architectures and road maps that promote standardized application architectures, facilitate innovation, and enable rapid product development.

In partnership with portfolio architects, the EA practice manages application architecture across multiple business solution delivery teams and develops business-aligned IT strategies. Each strategy contains a road map of initiatives that translates to measureable action and IT commitments to the business.

Road mapping is a core planning competency for architecture, engineering, service, and operations. It supports such business and IT goals as service management, portfolio simplification, prioritization, and IT-business alignment. Using a common tool, a consistent lifecycle management standard, and a standardized architecture governance process, three types of road maps are created: Technology road map; Reference architecture road map; Utility/capability road map

... business solution delivery teams to bring products and services to market faster by reducing infrastructure procurement and provisioning

... reference architectures [result] in fewer service outages, increased standardization of infrastructure, improved mean time to repair, and a dramatic decrease in support costs.

… extending its road map coverage to encompass: the rationalization of business capabilities and the maturing of SOA. ....

Bayer Healthcare

... history of mergers and acquisitions,

… launched its EA Management program with the creation of a global, Web-based Standards Management Platform ...

… is designed to act as a "knowledge bridge" between business operations and IT. ...

... Application Portfolio Portal [and] all related processes.

… online portal is available to all IT and business managers across the company. [many EA and plans team focus on a narrow audience – creating a silo of use]. Users can log in at any time to find an application and its related process data. The repository builds in application lifecycle management and proposals for specific activities, such as migration, integration, toleration, and elimination.

… includes assessments from business, technology, and financial perspectives and identifies application gaps, overlaps, and improvement opportunities. Applications are inventoried and registered against key metrics, and data integrity is maintained through an ongoing data stewardship program. Of particular importance was the need to build in strong collaboration tools, so business owners and IT could more easily share and discuss change scenarios. To facilitate this, reports and visualizations can be generated directly from the portal...

First Data
... a provider of transaction-processing solutions with more than $10.4 billion in revenue and 24,500 employees in 35 countries...

... EA function has created a framework for strategic technology programs to coordinate technology adoption and development in a manner that maximizes value. ..Through them, First Data will transform three technology layers: application (SOA, platform rationalization), information (master data management, BI, data warehouse consolidation), and infrastructure (data center consolidation, internal private cloud, provisioning automation).

EA is intertwined with nearly every aspect of [the] business. Its ability to drive product transformation is critical; this project will rationalize and consolidate product offerings, driving efficiency, simplicity, cost effectiveness, and agility.

… effective collaboration with development and vendor partners to ensure the benefits of emerging technologies ... This includes leveraging internal private clouds with provisioning automation, integrating real-time communication services (IM, videoconferencing), deploying consumer technologies (iPads), managing 120TB of enterprise data migrating to a consolidated warehouse.

USAA

… provides a full range of financial services including banking, insurance, retirement planning, investment services...

… membership has expanded significantly, leading to significant change in business models

... formed a cross-discipline, cross-organization team responsible for enabling the business to change processes, methods, and structure to align with broader member needs and newly available technologies.

... a customer-centric approach solely focused on meeting the needs of its members. It provides a single road map, bringing together people, process, technology, and information, rather than stand-alone process design and IT roadmaps. The approach represents all architectural disciplines, including business architecture, information architecture, IT architecture, change management, and organizational design. The focus is on delivering business design processes and methods as opposed to models and standards.

... Another challenge has been unifying the architects themselves into a single, cohesive community and creating a metamodel and deliverables that all disciplines can agree to and benefit from. ...building a common repository, which will have joint ownership across disciplines and its own governance team made up of representatives from the architecture community.

Lawson on EA supporting the Business

2011-06-01T14:04:00.000-07:00

I think this is item is good and makes some key points

"... artifacts that are rigorous and approached as a science rather than as an art..."

"... instead of just discussing a business operating model through text ..."

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..."

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."

http://www.itbusinessedge.com/cm/community/features/interviews/blog/how-enterprise-architecture-can-support-the-business/?cs=47185&page=2

We also need to brings these concepts down stream into what business "analysts" and how requirements are discovered and elaborated e.g.

"... artifacts that are rigorous and approached as a science rather than as an art..." - what we need is are artefacts are rigorous and approached with semantic precision rather than as a story telling exercise in the "best seller list" book tradition

"... instead of just discussing a business operating model through text ..." - narrative is not always the best way of undertaking or recording analysis

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..." - and elaborating the Business Architecture as a part of defining requirements.

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."

Business Transformation Management, Business Architecture and Business Requirements

2011-04-14T15:22:00.001-07:00

I think this item is on the money: http://www.baselinemag.com/c/a/Intelligence/Transforming-Data-Into-Information-849660/ [my comments inserted in square brackets]

"Transformation is an enterprise-wide activity, and the first step is to get a clear picture of the entire enterprise.

Most large organizations have used a variety of internal and external resources to document bits and pieces of the way they operate over time – organization charts, business plans, statements of policies and procedures, and the like. Many of these documents are of little value. They do not use commonly agreed-upon standards and terminology, are only partially complete, therefore they cannot be logically connected to formulate a cohesive picture. [So a common view of the Business context and Architecture is critical]

As a result, companies wrestle with a number of challenges:

- Prioritization hindered by competing business unit goals;

- Isolated process design resulting in loss of linkage to business objectives and unrealistic technology requirements;

- Overlapping business systems proliferating as a result of uncoordinated business units and mergers/acquisitions;

- Critical processes relying on temporary ad hoc “solutions” thrown together to meet immediate needs;

- Lack of asset reusability; difficulty communicating and defining standards;

- Difficulty keeping pace with technology change and vendor competencies;

- Enterprise architecture models that are too technical and detailed for anyone aside from those who designed them to understand and follow.

[- Projects are initiated with no clear explicit linkage back to the business context and with no ability to understand gaps and overlaps betweens the set of transformation initiatives]

For successful execution to be a remote possibility, an enduring transformation requires

... management framework that unites a company vertically – from the board room to the project team, as well as horizontally – across all divisions and including external partners and customers.

... strategic investment management, they have consistent processes for sponsoring, selecting and managing initiatives [So sound Business case development, based on the Business context and Business architecture is key].

... standardized means of structuring projects [and especially the key input to transformation initiatives such as projects i.e. the business requirements]

... ensuring that [transformation] are managed in accordance with enterprise standards.

... standards for determining the demand and the supply of resources—human, financial, fixed, and other—for future initiatives.

For these organizations, data has become information, which is managed effectively across the enterprise and used as the basis to make decisions accordingly. And, in large measure, this information is available through and managed in an integrated, enterprise-wide automated system that facilitates decision-making. These organizations understand both the specific strengths and the limitations of point solutions, and they have created management dashboards and other tools to make decision-making and management consistent. [This enterprise wide system contains their business context, business strategy, business architecture, business transformation initiatives and the associated requirements, the existing assets (including technologies) and views of new assets to be aquired). The systems isn't however focused on the detailed engineering of the technology assets (any more that it is focused on the detailed engineer of cars, building or other technologies).]

Now engaged in continuous process optimization: they learn, adapt, implement, and improve, in an ongoing cycle ... They conduct fully data-driven decision-making enabled by a consistent, coordinated, and integrated use of automation. Every professional has an appropriate level of access to enterprise-wide information, analysis, and management tools, and the enterprise makes this uniform, data-driven model fundamental to its way of doing business. [That is to say this critical information is just held within provence of a few strategists or architects]

“Every piece of business strategy acquires its true significance only against the background of that process and within the situation created by it.” .. the reality is those same principles and a transformative set of repeatable processes are what’s needed to build strong, healthier companies..."

Also see:

http://www.baselinemag.com/c/a/IT-Management/Beyond-Business-Models-427438/

Most large organizations have used a variety of internal and external resources to document bits and pieces of the way they operate over time – organization charts, business plans, statements of policies and procedures, and the like. Many of these documents are of little value. They do not use commonly agreed-upon standards and terminology, and are only partially complete. Therefore, they cannot be logically connected to formulate a cohesive picture.

More thoughts on EA

2010-12-09T15:53:00.000-08:00

This is pretty good - http://www.infoq.com/news/2010/12/ba-model-ea

I agree

"EA for the sake of doing EA ...flounders aimlessly in search of respect....IT needs to start thinking more like the business and less like engineers"
"EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role" ...
"... capability map as a portfolio of business components ...the next level of details need only to be captured as new programs require them."
" ...traditional views of EA (People, Process and Technology) are too simplistic to support the diversity of business models. [Need] ...business architecture assets targeted at different levels of abstraction and produced in a contextually appropriate way to facilitate a far greater federation in decision making and implementation.]
"... you can no longer afford to ignore the ecosystem in which the enterprise operates"

I disagree that:

it is "... impossible to keep a centralized view of how the enterprise works -at a cost that would justify the value of such a view. ...". However maintaining a view requires changes to methods and tooling so that view accretes as a natural by-product of other activities and does not require capture for its own sake (Cf. cadastral data capture).

Interfaces

2010-11-29T18:00:00.000-08:00

I am often asked what the right way to record interfaces is. The answer is really that it depends what you want to know about the interfaces and that in practice you will probably want to record information at a number of levels

Let us examine another communications paradigm we are all familiar with – Bill communicating with Bob.

Should one record that:

1. Bill Communicates with Bob (remember communication may be multimodal)

2. Bill makes sounds with his mouth that Bob hears through his ears (and similar for other modes with different input and output interfaces).

3. Bill makes sounds that are communicated via a medium (e.g. air), or converted into electrical signals and transmitted via an electrical cable, to a switching mechanism etc.

See diagrams of three example options below

There are a myriad of other strategies e.g. Bill communicates with clients (and Bob is a client); or Bob's brain interprets the sounds and hears the words and emotional content, etc. Then there are the issues associated with the semantic content of the message e.g. do we want to record that Bill is communicating about Products, Pricing or whatever

Well it really depends on what we are trying to understand – if we want to understand communications flows in a organistion, or if we are designing a phone etc. It make be useful for different purposes and audiences to record this at many levels and to be able to relate these different views together.

Unsurprisingly the same is true when one considers who to record communications between applications. The way you record them varies based on the purpose. They may be recorded in multiple ways and it is very handy to be able have a way of see how all the different levels are related. But searching in vain for a single way of recording interfaces that will serve all audiences and all purposes is unlikely to be productive.

Traditional processes and EVP no good for EA

2010-11-25T10:50:00.000-08:00

Even Microsoft is now saying "Traditional enterprise architecture processes do not work" (said by Gabriel Morgan, principal enterprise architect of Microsoft 10 days ago). He also said other things we have said for a long time e.g.

- "We have to prove IT’s value to deliver that market position"

- "We cannot develop a sustainable target architecture if we don’t know where we are"

So perhaps EAs will one day listen and stop doing what they have done i.e. using Excel, Visio and Powerpoint to try and do EA and look at what is actually required.

Dealing with complexity

2010-11-25T10:19:00.000-08:00

I think this presentation indicates how useful visualisation are in dealing with complexity.

http://www.ted.com/talks/eric_berlow_how_complexity_leads_to_simplicity.html

It mentions that it is important to set back and embrace complexity, and then look at issues in context.

It also demonstrates how dynamic visualisations can be powerful in analysis where one can selectively hide, decompose etc. the views. And to my mind why static crafted hardcopy reports will often struggle to allow us to examine new issues that arise, and what-if analysis i.e. it is the ability to interactively explore the data from many perspectives that is critical to the insights.

It is only by understanding how to deal with complexity effectively and good using solutions and tools to deal with it are we going to get any better at making strategic transformation or optimisations of the increasingly complex systems that are large enterprises.

EA's need to understand money and be prepared to change

2010-10-13T14:26:00.000-07:00

I do not know what to make of some central Enterprise Architecture functions who do not seem to appreciate the need for transformation or have a grasp of economics. Transformation is about changing how we do things. Economics must ultimately drive all EA activities i.e. a strive for business value, and understanding of cost alternatives etc. Or more accurately they have academic understanding they advocate for others but are relucant to apply to themselves.

These functions will happily create a central repository of information about the enterprise that is critical to executive decision-making and optimal excecution of initatives. Yet they persist seeking to create artefacts from this repository e.g. documents, PDFs rather than just let others in the enterprise directly access the information and keep it up to date themselves.

When asked why they don't provide access they cite cost of providing access and that people are used to getting documents and don't want to change.

I recently examined the cost issue. I calculated that the cost of providing direct access to accurate online information that can be drilled down in to, and dynamically visualised. I then equated that cost to the cost of the people's time. It showed the cost for access or visibility is less than the cost of 1 minute of the person's time. The cost to provide people the ability to interactively update the data (and then do what if) would cost perhaps 2-3 minutes of the person's time.

So clearly any rational analysis would suggest cost is not the issue, which leaves us just with the business change issue i.e. changing people's behaviour.

Some recent thoughts on EA

2010-08-02T21:32:00.000-07:00

Comments on 5 useful recent thoughts from others on EA (and some others)

My conclusion.

I think we can see a broad consensus on the need for more focus on business issues; collaboration and communication (speaking in language business understand not technical terms/languages) etc. Most importantly the need for vision and leadership.

1. The Quantum of Integration: http://advice.cio.com/brian_hopkins/10949/the_quantum_of_integration.
.. The act of thinking about something from different perspective actually influences the architecture. The focus on the business issues (e.g. capabilities) is often what one finds lacking.

2. Trends in Enterprise Architecture:http://advice.cio.com/brian_hopkins/11157/trends_in_enteprise_architecture
I agree there will be
- ... more business focused, delivering measurable value through strategy, governance and focus on critical interface between key enterprise components.
- ... more emphasis on strategy, process and governance and less on frameworks
- ... important skills for EAs are shifting toward the Business and Information layers in the Architecture domain stack
- ... EA activities that provide immediate value to the business are better first steps towards maturity. Focus on providing easily consumed, strategic deliverables that executives can use to make decisions
- ... Less "boil the ocean" analytic exercises with dubious short term value will be tolerated.
- ... define repeatable processes for producing EA deliverables then measure progress against these with a set of metrics.

3. Collaboration in EA is the key to Success -http://beyondea.com/2010/04/collaboration-in-ea-is-the-key-to-success/ is an excellent item by Denis Suto

4. The state of enterprise architecture: Vast promise or lost opportunity?
http://www.it-analysis.com/business/change/content.php?cid=12213
Fehskens:
... the discipline of EA and compare it to mature professions ... we’re back 200–300 years ago.
... you have to be able to do it [make the argument] in the language of the audience that you're speaking to. This is probably one of the biggest problems that architects coming from a technical background have.
Ross:
... reluctance to think that the way we get more value from IT is basically by taming it, by establishing a vision and building to standards and understanding how that relates back to new ways of doing business, and actually developing standards around business processes and around data.
... The architect’s role is to make sure that there is a vision....
... "... we need to begin generating value from more disciplined processes."
Hornford:
... underpinning all of that is what is the business trying to achieve? What is their vision and what is their goal?
... have to be very clear on what is the end state, what is the goal, what is the business transformation, and how will the digital assets of the corporation—the IT asset—actually enable where they’re going...
... fundamental with leadership in EA is that architects don’t own things. They are not responsible for the business processes. .. They are responsible for leading a group of people to that transformation...
... If you don't have good leadership skills, the rest of the fundamentally doesn’t matter
... If you do not lead and do not take the risk to lead, the transformation won’t occur. One of the barriers for the profession today is that many architects are not prepared to take the risk of leadership.

5. Chris Curran's EA blog - his comments in blue, my views bold:

- An exhaustive enterprise level blueprint is virtually impossible to build

Wrong and based on the wrong premise, it is like saying and exhaustive view of our finance (accounting) or customers (CRM) is impossible to build. Obviously it isn't if it built using an enterprise by the enterprise.

- The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints

Perhaps, not if the strategy is to abandon or outsource the unit/domain.

- Centralized accountability for the EA function is a predictor of success - A centralized team of architects is critical in driving EA standards and approaches

Partly correct, a centralised team of people anyway (architects may focus on the wrong things) and a these in fact to be engage a distributed set of SMEs, the project teams how consume.
- Architects must be assigned to projects as core team members - perhaps. Are town planners assigned to building design projects.

Maybe. Governance shouldn't be done by pursuasion or covertly (the town laws, or electrical wiring code doesn't pursuade adoption - it is mandated)
- EA should be measured in 2 ways: business capabilities delivered and costs of core services

Wrong - I would say their are other ways e.g. risk reduction
- Measure EA as an asset

Perhaps, but it is hard do measure the value of a better strategy? It is easy to see Steve's Job's strategy was right now. If it was obvious before hand why didn't others do it.
- Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function

Yes.
- Methods and governance must be integrated into existing work processes rather than an overlay

They be both (see town planning - methods are integrated into delivery and their is an overlay checking compliance).
Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better

Yes.
- The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)

Probably - I have not seen the facts
- Leading companies have reference architectures in place for 90% of the technical domains - Maybe - I have not seen the facts
- Senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users

Yes.
- High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates

Yes.
- Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks

Maybe.
- Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time - Yes.

Some others:
http://www.zdnet.com/blog/service-oriented/four-ways-to-boost-enterprise-architectures-business-value/5240
http://www.infoq.com/news/2010/07/ArchitectureStrategies

Capability maps for Business Alignment

2010-08-02T21:31:00.001-07:00

Don't Just Build Business-IT Alignment, Map It: http://www.businessweek.com/idg/2010-07-26/don-t-just-build-business-it-alignment-map-it.html. This is a really useful item. My precise below.

CIOs need to be able describe IT functions in business terms. Alignment occurs when people have a common understanding of what's important to the business, how this relates to the business model and the supporting technology, and where to prioritize investments for measurable improvements.

Business capability maps provide a framework to capture, assess, and communicate these needs. These maps put technology strategies in the context of the business process, functions, and capabilities they affect, and help enterprise architects design application and information architecture.

There are no industry standard models or frameworks to guide architects in their development. Forrester developed a six-step process that provides the foundation to successfully build and apply capability maps.

Step 1: Identify the Business-IT Alignment Issues - interview stakeholders to get differnt perspectives. Start with IT and use the results of those interviews to refine the process before moving to the business. Analyze the interview data to find common problem areas. Validate the identified problems with stakeholders to ensure that the accurately reflect their concerns.

Step 2: Define Your Approach - Create a current-state view that includes the issues and a future-state view. Use the current and future-state views to map alignment Issues to solution options. Focus on tractable issues. Define the roles and resources needed to make the initiative successful.

Step 3: Develop the Business Case - Develop a resources project plan (showing ramp up). Identify risks and mitigation approaches. Determine tools and technologies. Develop a cost estimate. Sell the business case.

Step 4: Build the Capability Map - Determine your organising principle e.g. value streams, business functions, services to clients and define the capability framework. Validate the structure by focusing a single element and identify capabilities for that element and add details (narrative description, people, process, technology, information, business goals, metrics, and gaps). Repeat across all of the organizing elements.

Step 5: Apply the Capability Map to Identified Problems - Create a capability map view to that focus on the decisions to be made. For exmaple for investment decisions analyse performance of core capabilities that provide significant market differentiation and competitive advantage to see where investment need to be made.

Step 6: Assess Progress and Refine the Approach - Examine the work to date. Re-examine interim deliverables. Identify unforeseen issues that affected progress, and plan forward and adjust the framework based on knowledge gained.

ESTO success sealed with a KISSS?

2010-06-03T17:26:00.001-07:00

Once again I feel compelled to suggest that we learn about how to implement Enterprise Strategic Transformation and Optimisations (Enterprise Strategy and Architecture, Strategic IT planning etc.) from another domain focused on the enterprise use of knowledge and collaboration based on that knowledge i.e. CRM.

See: CRM Success Sealed with a KISSS - http://www.computerworld.com/s/article/print/9177484/CRM_Success_Sealed_with_a_KISSS?taxonomyName=Applications&taxonomyId=18

Most people with experience in trying to change patterns of behavior know that incremental change is easier for people to accommodate. Most people with experience in trying to implement systems know that big-bang approaches are high risk. Implementing new systems for knowledge management and collaboration involves both i.e. changing behaviour and implementing systems.

ESTO solution projects also "need to be much more flexible and adaptive than general IT applications. All too often, the users don't really know what they need, and the smart ones will admit it. Even if they did know, the business rules and your company's competitive environment will change before an 18-month "big bang" project ever gets deployed. ESTO projects are not only less expensive when delivered incrementally, they are a better fit with the business needs. So it's important to get your project staff -- and the ESTO system's executive champions -- comfortable with Agile.

Personally I have issues with methods that are focused on, or derive from, SW development being applied at different levels. And I think that SW developers per se are too keen to see each problem as one that requires development i.e. to get 100% fit might require development; but using an OOTB solution that reflects best practice might get you 80% of the way there - in 10% of the time.

I think the comments on vendor roadmaps interesting - and what we really need in ESTO is an aspirational roadmap with features defined near release drops.

See other ideas from comparisions with CRM:
- http://enterprisesto.blogspot.com/2009/08/what-price-sitp-data-quality.html
- http://enterprisesto.blogspot.com/2009/07/8-dirty-little-secrets-of-enterprise.html

Virtuous circles of strategy, architecture and delivery

2010-05-26T18:56:00.000-07:00

If we don't support a virtuous circle of use - we won't achieve much (and certainly not cost effectively).

The majority of people who need to consume an Enterprise Architecture and Strategies are business teams (owners, analysts etc.) and solution architects, designers etc. i.e. down-stream project teams wanting to do something (buy, build, change etc.). NOT other EAs and Strategists. You can see the same thing with a town plan i.e. the majority of people who consume the town plan are property owners, architects etc. wishing to do things.

Governance functions also have a need (e.g. project office, contract/vendor management, business case analysts).

Until EA can effectively understand its place in the lifecycle of think, plan, excute, operate - it will struggle.

Enterprises wish to make changes (transform, optimize) and EA is intended to guide these changes (it is not an end in itself). The changes will usually be implemented in initiatives, programmes, and projects. Those involving IT will usually have requirements, solution architectures, etc. These projects are where the rubber hits the road.

So EA needs to be consumed by down-stream projects - which will indicate their use of existing assets (applications, services, interfaces, hardware etc.), standards (products, technologies, patterns), capabilities (skills, resources) - and indicate where they will produce new assets or require new/different standards to be adopted or capabilities established etc.

Most of what one sees in a tradional EA once came from some project that drove the need for it. This is true on the business and technology side - but is usually more obvious with technology.

An EA needs to be produced and consumed both bottom up and top down.

EVP - Powerpoint fails to deal with complexity well - who would have thought

2010-05-06T21:58:00.000-07:00

I have heartened to see this "U.S. Army discovers PowerPoint makes you stupid" (http://blogs.computerworld.com/16006/powerpoint_makes_you_stupid?source=CTWNLE_nlt_entsoft_2010-05-03).

For many years I have been presented with powerpoints that claim to communicate complex things e.g. strategies, roadmaps, architectures, transition plans etc.

I have been perplexed when on examination the PPTs turned out not to contain the information necessary to describe the complex situation being dealt with. I am then asked how do we model these - or why can't you produce a model, visualisation or report that communicates like these do. The reason is that the powerpoints are often specious - being favoured by executives, sales people and other trying the illusion that analysis has been done and sound conclusion reached based on facts - when in the facts, analysis and conclusions are at best usually disconnected. If one points out the limitation of the powerpoint source documents - one hear "Oh so you don't know how to represent this". Well the answer is that if the data is rubbish expressing in a semantically precise way will just highlight that it is rubbish. This doesn't to fly well with the executives.

I like these quotes:

"Have you fallen in love with your bulletized slides, nifty transitions, and pretty charts in PowerPoint? If so, you're likely getting more stupid ..."
"... We Have Met the Enemy and He Is PowerPoint... When we understand that slide, we'll have won the war."
"It's dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bullet-izable."
"... it leads to bad decision-making, with serious consequences ..."
"... that tremendous amounts of time are spent in the military on putting together presentations, and that this takes away from true productivity."
"... [PPT] does come in handy when the goal is not imparting information, as in briefings for reporters." [or executives]
"hypnotizing chickens."

Artifacts vs Business Results

2010-03-17T17:43:00.000-07:00

I am often involved in looking at how people can improve their IT processes e.g. in areas of strategy, architect, governance and service delivery.

Firstly let me say I am fairly familiar with principles underlying OO analysis and design techniques having started using them in the mid 1990s (before UML, and before Java). Naturally when UML emerged as a defacto standard we moved to it; and to RUP which followed soon after. Having overseen many large projects using OO analysis and design techniques I think I have some understanding of what needs to achieved.

Now an apparent digression - Almost 30 years ago when I specialised in CAD and Mapping systems I used to have to explain to Architects, some of whom had been my tutors, the benefits of CAD. They pulled out beautiful water colours and asked if the CAD system could produce them. They had mastered the skills of producing these works of art over lifetime and were justifiably proud of them. At the time the answer was "no". Of course the CAD system could convey the essential information but the way in which conveyed it was different. And of course the cost to produce any ad-hoc view (plans, elevations, details etc.) or deal with changes using the CAD system was far lower. Also the CAD system could be interactively inspected, do counts etc. What these artisans failed to grasp was that what the client wanted as business not a water colour i.e. the business result was the building, the water colour artifacts were incidental.

I now encounter the same issue with people looking at various artifacts related to manual methods of solution design - the classic being the large SAD (seldom if ever read by anyone but the author) or in strategic area some large attractive diagrams manually created with many pretty colours. People seem to think the artifacts (e.g. SAD, Roadmaps etc.) are important per se. In my view they fail to focus on the business results to be achieved e.g. a transformation to be made, or a project delivered and really examine what information is required by whom, when, where and why.

I had a lot of sympathy for those being asked to move from water colours. While they required an experienced practioner and some time produce a result was aesthetically pleasing and communicated very well to many audiences i.e. technical and non-technical (if limited to a specific point of view e.g. plan, perspective, detail, elevation etc.) I have a lot less sympathy with IT people today wasting energy trying to replicate some arcane symbols (e.g. associated with modelling logic, processes, objects or data). These also require experienced practioner and some time produce. The result are neither pleasing nor particularly communicative to average person.

Business architecture as part of Enterprise Architecture

2010-02-10T18:20:00.000-08:00

I saw this and thought some of the quotes interesting
http://jccavalcanti.wordpress.com/2010/02/10/defining-business-architecture/

"...BA is an intrinsic component of EA, but what most people really perform in most organizations that I see is IT architecture."

"... enterprise business architecture is a set of artifacts and methods that helps business leaders make decisions about direction and communicate the changes that are required in order to achieve that vision."

"... It's our excuse sometimes that it's too complex to change quickly."

"... We really need to focus the conversation on capabilities..."

"... BA is a means by which we can engage as IT professionals with the business leadership, the business decision-makers ...

"... By having that meaningful dialogue on an ongoing basis, not just as a result of the big implementation ..."

"... understanding your audience is a big part of doing this.

"... That's why there's no, "This is the artifact to create." ..."

"... there's a missing linkage between that vision, that strategy, that direction, and the actual activities that are going on ...

"... jump from high-level strategy down to tactical daily decision-making and activities is too broad of a gap. .."

To me this supports my view that:

1. The BA is intrinsic to EA (though EA function focus on technology).
2. EA needs to support decision making and communicate what needs to be done to achieve a vision (goals, strategies, plans and down to requirements)
3. The excuse made that it is too complex to change quickly indicates a failure of EA.
4. BA needs to focus on capabilities and allow us to engage with the business leaderships (so we need to use the right language)
5. Waiting till a big project to justify the dialogue is like waiting until you are attacked to learn how to defend yourself i.e. it is just dumb
6. Understanding the audience is critical and what and how you communicate varies based on the audience.
7. There is a missing linkage between that vision and plans that live in PPT decks on the shelves and what happends on a day to day basis.

Communicating with people in languages they understand

2010-02-06T13:41:00.000-08:00

For many years I have run foul of SW developers how have migrated into Architectural roles - but want to continue to use the techniques and languages suited to the role of OO SW development.

Open Group advocates are often some of worst as many are committed to UML - a language manifestly unsuited to communicating with most business people most of the time.

I recently read this: http://blogs.zdnet.com/Gardner/?p=3450. And saw these comments:

"To achieve business-IT alignment, architects need some way of understanding what the business is really about. ...

We need to talk to business people to understand what the business architecture is, but the business people don’t want to talk tech-speak. ...

We need to be able to talk to them in their language, but addressing an architectural end. "

And I wonder when the penny will drop that this language isn't UML.

What impedes the development of Information Architecture

2010-01-22T14:22:00.000-08:00

Prompted by: Forrester: Information Architecture Matters - Survey of enterprise architects finds information architecture is immature and undervalued.
http://www.information-management.com/news/forrester-information-architecture-matters-10016994-1.html

I think the obstacles of IA is the preponderance of people involed who see data in relational database terms (or in terms of other implementation methods and standards) rather than in terms of the business questions, knowledge and information.

One sees similiar, but perhaps lessor, issues with business architecture where the people involved want to see things in terms of Use cases and techncial process execution (e.g. BPEL) - rather than focusing business capabilities, functions and process.

The higher levels are intrinsically less transient and not really related to technology per se.

In both cases the boil-the-ocean problem arises from starting at the bottom of the pyramid rather than the top. The absence of a sound top level means the framework for progressively elaborating lower levels as a by-product of execution projects doesn't exist (or isn't used).

Forrester proposes a process or methodology solution - but the solution in changing the people i.e. changing the behavior of people in the roles; or changing the people who inhabit the roles.

It seems to me nothing much has changed since I wrote this
http://ea-in-anz.blogspot.com/2007/09/enterprise-data-management.html

In this I identified some things:
- Information management strategies are going to have to improve.
- Most organisations can't even provide a high level map of their information - it is buried in silos (maintained by a technical clergy with arcane interests)
- Most organizations don't have a handle on the relationship between business information and the underlying ICT systems that implement the data
- Most organisations can't explain what information is associated with what: process, service, rule etc.
- Most CIOs can't have candid conversations with their business counterparts about what the real issues are associated with managing todays data or dealing with more data.

I suggsted some things that should be done
- a knowledge base which could act as hub
- the boundaries between the hub and the various spokes (e.g. ER modellers, XML modellers etc.)
- inventory data and usage
- benchmark against industry Reference Models
- defining architectural principles and goverance approaches
- analyzing business information context
- develop optimisation programmes

Inspired by "13 Enterprise Modeling Anti-Patterns & How to Avoid Them"

2010-01-14T16:03:00.000-08:00

I saw this today: 13 Enterprise Modeling Anti-Patterns & How to Avoid Them [
http://www.linkedin.com/e/avn/103346240/1814869/EML_anet_nws_title-cDhOon0JumNFomgJt7dBpSBA/]

I thought it presented some useful points albeit often otiose. It mixes two issues i.e. how to do enterprise modelling (SITP) and what the results of good enterprise modelling (SITP) should be e.g. avoiding immature or unstable technologies (except in rare circumstance) should be a result or conclusion from for SITP - but it doesn't really tell us about SITP per se. I am interested in SITP and focus below on aspects that relate SITP method.

I think it can really be boiled down to 3 things

1. Audience, Purpose and Use are critical - The one thing it repeats many times in many ways is that you need to model with an audience, purpose and use in mind. This means models won't be too detailed i.e. if they are fit to purpose. It also implies that you will look at how to engage with the various stakeholder (rather than doing what suits developers who in my view have often hi-jacked the process). Lastly this means that you must have some idea of a path to implementation as few stakeholders will proclaim to know things for no purpose other than to know them i.e. stakeholders will clearly say we want to know so we can decide and act.

2. Ongoing knowledge accretion - It also points out that you need to roll things out (when they are not perfect) and let them evolve and mature.

3. Know what you know - Understand what you are capturing e.g. an essential aspect, just how it is today (but not how we would like it to be), how we would like it to be (but not how it is)

The things it say to avoid (with by comments in [ ]) are:

30,000 feet and climbing
- avoid models that are too high level [well this is tautology];
- ensure models have a practical use [but this is absolutely key]

Detailed enterprise model
- model just enough detail [this really comes back to understand the use i.e. the point above].
-- Model with a purpose [yes].
-- People rarely read the details [Well this really is a problem with the concept of models and it is most people are not interested in most detail (detail about other peoples domains]. This is not to say that the detail should not be understood or recorded. It is to say that the detail should only be presented to the people to whom it is of interest and when they want to see it]
-- Know the audience for the models [absolutely - or more accurately understand the audience for views of the data that answer question they care about]

Ivory tower architecture
- Create realistic models [?? what other kind of models are of use??] rather than perfect world scenarios [?? well surely one need to know how one would like things - this seems to conflict with a point below]
-- Get Development teams involved early [?? why on earth would you set out with the aim of doing development, surely development is necessary evil not something to be encouraged by premature engagement of people who like doing it]

Modelling for modelling sake [absolutely]

Real world disconnect - ensure models reflect the actual stakeholder requirments [absolutely]. So don't use arcane developer oriented modelling approaches e.g. UML, ERD etc.

Striving for perfection [there is nothing wrong with striving for improvement].
- Roll stuff out even if it is not perfect [This is the key aspect. The information and process needs to evolve progressively with the involvement of the whole community]

Getting stuck in the weeds [Well I would say - avoid capture transient implementation specific details unless they are critical for some reason and capture the essence of the issues]

"Technology above all" [yes] Make technology a business enabler not a business driver [well the fact is that sometimes the market/environment means that technology is or should be a a driver]

"Tomorrow suffers from today" [record how you would like things to be - which is why it is important to understand the essence of things vs. just their current implementation]

"Underground Future" ensure models create a clear path [yes - with out plans, initiatives and transitions a vision is not that useful]

"Yesterday's Enterprise model" - Once finished don't let your models get out of date [well this is oxymoronic. One never finishes, the models are an ongoing active record]

Economics and Enterprise Architecture

2009-10-28T17:03:00.000-07:00

I thought this quite a good item (http://virtualization.sys-con.com/node/1159476).

It touches indirectly on a couple of points e.g.
- Getting the right answer requires that you pose the right question.
- You need to ensure the cause/effect relationships are valid if you know your conclusions are correct.
- Assumptions and theories need to be tested by identifying the variables that need to remain static and then testing changes.

Having observed much EA/Strategy work I think that this makes some fundamental assumptions that are typically wrong e.g.
- that cause/effect relationships are made explicit and testable
- that assumptions and theories (or beliefs) are stated as such and their rationale made explict.

See: http://ict-tech-and-industry.blogspot.com/2009/03/business-analysis-and-visioning.html

It also says:
"Unfortunately, you cannot demonstrate the value of Enterprise Architecture if you cannot monetize or enumerate the value of all possible choices relative to the choices that are being recommended or those that have been made. "

To me this is kind of ducking the issue - i.e. one can never know all all possible choices that could have need made (let alone monetize them) - this is the intrinsic problem of counterfactual reasoning I published a few years ago http://ea-in-anz.blogspot.com/2007/08/justifying-architecture-and-strategy.html) see summarised below:

There are always challenges in valuing and justifying, good (or often any) design, strategies, plans. The problem lies in a number of areas e.g.:

- Challenges with Counterfactual reasoning - In most situations one can't easily compare the result of what was done (designs/strategies/plans) with what could have been done.

- Self-interest: militates against sharing knowledge. Knowledge is power and sharing knowledge (e.g. the basis of a decision) can diminish ones power and one one up criticism (e.g. regarding the veracity of the data or the soundness of the analysis).

- Secrecy: sometimes one does not wish to disclose a strategy/plan. Often the downside of secrecy is that people in ones own team or side, don't understand what should be done, why, when etc. (i.e. the benefit of secrecy is outweighed by its impact on efficacy).

- Analysis and design is intrinsically difficult - strategy/design/planning, and modelling are often quite difficult to do well. To make matters worse the result can be seen, with hindsight, as trivial and not justifying the effort required. It is always quicker just to just act without thinking, and it may even be cheaper in the very short term.

- Future is someone else's problem - if what is done doesn't last, is expensive to operate, expensive to change etc. it is seldom the problem of the initiator, the initial designer, builder or user. It is a problem inherited by others.

While these issues can be seen all areas of life, ICT is particularly bad as it has not yet matured into a profession (where people have the requisite learning, training and discipline; and profess anything approaching code of ethics).

People wishing to ensure better strategies, designs and plans, need to look for others who:
- Intrinsically value better strategies, designs and plans, and can consider the future.
- Can overcome self-interest of knowledge holders and know what must be kept secret
- Know thinking is difficult, takes time and money and are prepared for the effort.

Industry Reference Model framework

2009-10-26T18:54:00.001-07:00

INTRODUCTION

Systems need to be established and evolve and over time. Therefore an understanding of what lead to the current state is critical. These endeavours include a gamut of challenges: regulatory, governance, policy, institutional arrangements and agreements, organisation structure and roles, skills and capabilities, technologies and technical standards, transitional and phasing, etc. To often this knowledge departs or lies in thousands of documents and files.

There are existing best practices emerging in how to establish industry frameworks. There use addresses: recognised issues associated with the implementation of complex information systems by government; assists using in capture knowledge in a semantically precise way; allows specific local implementations to be supported that can be mapped to external reference set (that reflect common best practice).

In implementing a system one needs to ensure it can evolve. This allows it to be extended to address future needs. The evolution of systems requires that the raison d’être for the design of the systems and organisations is understood i.e. so that experience is institutionalised and retrograde “enhancements” can be avoided.

This framework must ensure semantic precision and allow easy case by case instantiation. It relates patterns, principles, standards, modules (or build blocks), reference models and maturity levels. It allows the adoption, emphasis or abnegation of the elements in the framework in each specific implementation to be made explicit. This allows the framework to be common – while each implementation is different with a mapping between the common framework and the specific implementation

ANALYSIS OF PROBLEM

Complicated systems

Complicated systems and relate to complex organizational structures. They are typically networks of systems, distributed and loosely coupled, in federated or discrete organizations, serving a multitude of purposes and audiences, support transactional and archival functions. To address the problems effectively we need to learn from other complex disciplines better and recognize that many of the best practice that applies to these apply to our systems.

Specifically we could start by looking at the generic problems associated with the implementation of complex IT systems (especially in government).

The Royal Academy of Engineering and and The British Computer Society observed that

"A significant percentage of IT project failures, perhaps most, could have been avoided using techniques we already know how to apply. For shame, we can do better than this."

They go on to say:

"It is alarming that significant numbers of complex software and IT projects still fail to deliver key benefits on time and to target cost and specification. Whilst complex IT project success rates may be improving, the challenges associated with such projects are also increasing rapidly. These are fuelled in large part by the growth ... in the capability of hardware and communications technology, and the corresponding inflation in people’s expectations and ambition.".

They examine how complex IT projects differ from other engineering projects, with a view to identifying ways to augment the successful delivery of IT projects.

Amongst their findings and recommendations are that:

– “A striking proportion of project difficulties stem from people in both customer and supplier organisations failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry, as well as inadequacies in the education and training of customer and supplier staff at all levels”

– The significance of systems architecture is not appreciated.

– Further developments in methods and tools to support the design and delivery of such projects could also help to raise success rates. In particular, basic research into complexity is required to facilitate more effective management of the increasingly complex IT projects being undertaken.

– There is an urgent need to promote the adoption of best practice amongst IT practitioners and their customers.

They also identify some things that we think most people have known for some time e.g. the need for good project management and risk analysis. However both of these tasks are significantly impeded if the underlying knowledge required for analysis is not available.

What issues does an framework address

A framework must help improve:

– collective professionalism – by providing all parties a way of undertaking analysis, design and planning in an effective and professional manner.

– education and training – by providing an explicit relationships between the outcomes, the procedures and systems, the organizations and roles, and the skills required.

– architecture – by provide a template for defining: sector or industry (NSDI) architect, the enterprise architectures and systems architectures

– strategies for dealing with complexity – by providing methods and tools that support the analysis, design and delivery of systems

– adoption of best practice – it is all to easy to speak of adopting best practice, everyone does, but in order to do this we really need to define what the elements of best practice are, how this knowledge is manner and provide a strategy for its adoption.

What capabilities does a framework need provide

It needs to allow federated group of participants to do a number of things, with greater transparency and more objectivity. Transparency helps people understand what and why they agree or disagree on things in an objective and unemotional manner. Reaching consensus is therefore easier. So it must be possible to:

– Capture drivers and requirements – these are the things that determine what a system should. Each and every elements of a solution (roles, skills, technologies etc.) must derive from these.

– Undertake analysis – a simple structured way to analysis is required. Analysis can be organised around simple set of canonical model (Goals, Facts, Beliefs and Recommendations).

– Design and decide – Designs are assemblages of elements. So we need to be able to record these things (and relate to externalities e.g. technologies). Design and decision making is made based on analysis of alternatives. So we have the information on drivers and requirements and are able to undertake analysis we can make explain the basis of decisions and designs.

– Plan, Programme & Phase – these require us to understand sequencing, prerequisites and co-requisites (implementation constraints). Intrinsic is the relationship between the requirements and the designs (i.e. the set of design constraints).

– Promulgate, educate, communicate and socialize – we need to be able to very selectively extract information for the framework that is suited to a particular audience, purpose or interest. What is keep is that we don’t need to manually re-craft communications artifacts for each different purpose or audience (and ideally we want information to be discoverable)

– Estimate the effort, costs, risk and timeframes associated with people, technology, procedures – in practice costs can only be effectively estimated by examining the proposed implementation i.e. the designs. But decisions need to be made related to the requirements and outcomes therefore we need to understand how the elements of the implementation relate to the requirements (and the marginal economic impact of each requirement).

– Support the validation, assessment, quality assurance and review – by making the above relationships explicit and transparent we provide a mechanism for doing this in a clear simple, and object way.

What is best practice (what can we learn from)

We can learn from a number of standards and approaches that are applied elsewhere by examining some existing methods e.g. ValIT (Val IT - is framework addressing the governance of IT-enabled business investments), COBIT (Control Objectives for Information and related Technology), OSIMM (Open group SOA Integration Maturity Model), CMMI (Capability Maturity Model Integration), FEAF (Federal Enteprise Architecture Framework), DODAF (Department of Defense Architecture Framework), TOGAF (The Open Group Architectural Framework), Zachman Framework , ITIL (Information Technology Infrastructure Library), IFW (Information FrameWork), DSM (Design Structure Matrix), Pattern Language (i.e. Alexander’s seminal work), TMForum.

These are from many disciplines e.g. engineering, architecture, portfolio analysis, defense, IT, telecommunications, etc.

Our approach to a framework is informed by these sources and others. The effectiveness of these approaches has in the past significantly impacted in most cases by their means of implementation (usually many documents and consultants). We need an approach that minimizes the need for both.

What does best practice suggest a framework needs to encompass

Space does not permit a full review of all of these but we believe that there is general consensus that following seem to make good sense:

– Business case and investment models – FEAF, ValIT

– Reference Models – FEAF, OSIMM

– Principles, patterns and anti-patterns – DODAF, Pattern Language, TOGAF:

– Principles – Pattern Language, TOGAF,

– Standards and technologies – TOGAF, FEAF, ITIL, OSIMM

– Modules (modularity, building blocks, e.g. service and components models) and collaboration models: indicating interfaces between roles and systems – IFW, DSM

– Taxonomies – DODAF, Zachman,

– Maturity models – CMMI, OSIMM, TOGAF (implied)

– Compliance mechanism – Cobit, FEAF, OSIMM. CMMI

– Different levels (of detail, of technicality) – Zachman, Pattern Language

– Instantiation – almost all of these frameworks allow instantiated instances

A FRAMEWORK BASED ON BEST PRACTICE

What analysis is enabled by semantic precision of the framework

In general we seek to provide a mechanism for better “analysis”. We proposed a simple model based on facts, goals, beliefs and recommendations. Where: goals are things you are trying to achieve, sometimes expressed as principles, issues (goals stated the reverse), visions, measures, objectives or KPIs; facts are not disputable and include laws, regulations, social factors and technical constraints; beliefs are based on facts and relate to goals and include causes, findings, implications; and recommendations are based on beliefs and achieve goals and strategies, plans etc. In addition we would want some grouping concepts (classification systems) for: terms, patterns, principles, technologies, standards etc. By support business or analysis with this paradigm we move for persuasive narrative to structured reasoning.

There are two types of specific analysis that we want to be able to do. I call them referential and inferential.

Referential analysis allows us to confirm that the relationships between element are correct this allows us to follow a path of relationships i.e. if this skill is unavailable what is affected, if this goal is to be achieved what is required, what elements are affected by this projects.

Inferential analysis is useful when we have compositions or when we have reference models - where we can related our implementation to the reference models. It allows us to infer what relationships should exist i.e. are implied to exist but do not. It allows us a check on correctness.

Reference models would usually be instantiated e.g. for example a functional reference models indicates a function is performed, our instantiation would indicate how we perform it. A data reference model indicates data we need, our instantiation would indicate how we manage it exactly.

While this seems obvious in this example when the relationships above are all described textually e.g. in a document inconsistencies are not so easy to see. Wven when they are dealt with graphically when there are large amounts of information (or multiple level of decomposition) these inconsistencies are hard to see. In both cases best practice would be to have systems do these checks (rather than checking for them manually).

What is the scope a framework

Therefore we propose a set of reference models which capture the fundamental issues

Determinants

Externalities that determine what a business does, how it operates etc. These are external factors that include: cultural and social, market and competitive, legal and regulatory, etc.

– Environmental, kegislative and regulatory reference model (ERM): describe the sets of laws, regulations and compliance issues (national and international), and local factors.

Strategy

Enterprise strategy, vision, mission, goals, strategies and plans (product, market, organisation), cases, governance and compliance, measures etc.

– Strategy reference models (XRM) – which relates to the Determinants and covers the vision, goals, strategies etc.

– Performance reference models (PRM) – which outlines the performance goals, measures etc. (Cf. FEAF’s PRM)

Operations

Enterprise operations - business: services, processes, rules, information (objects, documents, data etc.), organisation, facilities etc.

– Offerings, services and product reference model (OSM) – which outlines offerings, services and products which need to be provided to achieve the strategy

– Functional reference model – which outlines the capabilities, functions and steps, that must be performed to achieve the strategy (Cf. FEAF’s BRM).

– Rules and policy reference model – which outlines the rules and policies that are required by the strategy and determinants and to support operations.

– Information reference model – which outlines information, metadata and data required by the strategy and determinants and to support operations.

– Organisational reference models – which outlines the organizational networks, units, roles, techniques, skills that are required by the strategy and determinants and to support operations.

Systems and facilities

Systems and facilities including: applications and services, technologies and system services, facilities and internal utilities. The systems area could be further divided into business services and systems and technology services and systems (though the boundaries can become blurred)

Suppliers are externalities that determine the products, services, standards a business can use e.g. technology products, services and standards; product channels; real estate and facilities.

– Interface reference models – describes the interfaces, services and by implication the applications required for a system to operate.

– Technical reference models – describes the technologies, standards required to supports the interfaces.

– Vendor reference model – describes the products, agreements etc. required

Patterns and maturity models

Sitting beside the reference models are some knowledge bases:

– Patterns and template implementation plans – which indicate exemplar implementations and relate these to the reference models

– Maturity models – that outlines stage of maturity and relate these to the other aspects of reference models.

The 1^st three can be considered to represent the requirements and the last two are in the solution domain.

The Environmental, Technical, Vendor are effectively the external constraints.

These reference models are related to allow different types of analysis (referential and inferential) to be performed. They are most useful when they are related so as to allow impact analysis (both between domains, and within domains). Unfortunately many are often presented diagrammatically (great for communication, hopeless for analysis) or represented using inconsistent semantics, modelling paradigms that can't be related, or using arcane technology terms that are not meaningful to 99% of the world (e.g. use case, actor, cardinality etc.).

Need to be analysable from the top (and bottom) - this is why absence of Determinants is so limiting as ideally these would allow one to relate the circumstances to the strategy, and then from that the strategy to the operations; and the suppliers to the systems and facilities. It is why compliance issues seem so hard (and produce such a good feeding frenzy for consultants).

To be support modularity they can connect within each level and between each touching levels (in defined ways).

Need to be tailored and used carefully - as with all things that represent purported best practice they need to instantiated in-situ (using experience and judgement) to produce something that is useful in the specific set of circumstances. This needs to be done in a way that allows: the variations to explicitly understood and for the source reference models constant while being connected to detailed views of the enterprise e.g. the FRM may connect to existing detailed process models, the IRM may connect to data models, the PRM may connect to existing KPIs, etc.

Key characteristics of the framework

We can see a number of other key characteristics we require

– Implementation technology neutral and non-aligned – our framework must intrinsically technology and vendor neutral i.e. having no affiliation of alignment, and no preferred technology, products. This allows a clearer focus on the real needs and on standards.

– Accessible by anyone from anywhere – this effectively means Web accessible and is key so that knowledge can accessed where, when and by whom its it required and that knowledge can be capture as a natural by product of field work.

– Supporting different roles, scenarios of use, and levels of control – that is with role based access and presentation, so that people can see what they are interested in in a way that makes sense to them and can change information that is in their domain of control.

– Ensure semantic precision - which ensures it is analyzable, fully auditable, that the basis of decisions is explicit, objective and transparent. The lack semantic precision is one of the key problems with most, if not all, approaches based on documents.

– Represent idealised models – that has a holistic, coherent and complete set of well-structured, unambiguous and well partitioned and categorised set of business definitions (roles, functions, interfaces etc.). Has an explicit conceptual model of how the systems organizations are structured and operate (e.g. reporting, controls, data flows etc.)

– Divides the generic framework from the specific implementation - so the generic framework is reusable and extensible. Allows nations to maintain their know how i.e. how they do things, why they do things - rather than this knowledge be in the hands of third parties with vested interests e.g. consultants, vendors.

– Allows relationships and concepts to be – visualised, analysed and reported on.

– As simple as possible – to reduce complexity we limit connections within each level and between each touching levels.

CONCLUSIONS

We seek to make a non-incremental step to the way the systems are implemented. We believe that a framework with specific characteristics, capabilities and structure in order to allow best practice to be capture and applied. It is only by establishing this that we will significantly improve the efficacy of system implementations.

We can see that we identify many best practice methods we can learn and we believe there are better ways now available to implement a framework that will enable it operate effectively.

At present many parties are focused on capturing knowledge that should reside in a such a framework. Sadly much of the knowledge still resides in documents or in people’s heads where is not particularly useful (accessible, integratable, analyzable etc.) and frequently “leaves the building”

Facing some facts about EA

2009-10-22T14:09:00.000-07:00

Recent feedback from EA conferences - http://visualstudiomagazine.com/articles/2009/10/15/downturn-places-focus-on-role-of-software-architects.aspx

Zachman says:

"... we're not meeting expectations and we're not getting things aligned, we're not accommodating a lot of whatever the demands are from general management perspectives, their frustrations continue to escalate"
"...faced with the problem of addressing the conflicts between addressing short-term demand and keeping them in line with long-term architectural...if you don’t produce things in the short term you probably loose the opportunity to work on architecture...if you are not paying any attention to the long term you know you are going to end up with more of the same."

MJE - I believe the answer lies in see EA as an enterprise activity, and one that needs to evolve over time. This requires progressive changes to how the work is undertaken.

IASA president Timothy Leonard says

"..."The biggest call to action is to make sure people understand that information is key, that organizations are trying to build applications but build architectural designs,"

MJE - Well yes information is the key to management. I would suggest most enterprises are not actually seeking to build applications - they are seeking to build business (where development usually a necessary evil).

Grady Booch says

"You've got to have architects that have skin in the game, in the ideal I prefer my architects also cut code,"

MJE - Yes, and I prefer my brick layers to lay bricks. But I don't want them doing down town planning (or designing a building for that matter).

Gartner's have identified 10 pitfalls of EA.

2009-09-02T16:21:00.000-07:00

I see Gartner have identified 10 pitfalls of EA - http://www.tradingmarkets.com/.site/news/Stock%20News/2507730/.

It is quite useful (and better than their effort last month) however I think it is wrongly factored - and there are really three things (Like most areas it requires: right people, process and technology) based on the right focus.
a) The Wrong Lead Architect i.e. right person
b) Insufficient Stakeholder Understanding and Support (Technical and Business) i.e. right focus
c) Not Establishing Effective EA Governance Early i.e. right process
d) Right technology [which Gartner fail to identify - presumably for fear of alienating some of their major sponsors]

The rest are simply manifestations of these things i.e.

1. The Wrong Lead Architect - to often "Architects" have primarily self-selected to deal with technology not people and is the role of EA moves from applying knowledge to managing knowledge across the enterprise stylist changes are required.

See: http://ict-tech-and-industry.blogspot.com/2009/01/12-step-program-for-enterprise.html

2. Insufficient Stakeholder Understanding and Support: when people outside the EA team don't use knowledge organised by the EA team in projects (and they don't gather data from projects). This requires clarity regarding the roles of EA and SA (and other elements in the enterprise) and for the EA team to realise they are NOT the primary audience of EA (and in fact can't do EA - alone).

http://enterprisesto.blogspot.com/2009/02/enterprise-architecture-cant-be-done-by.html
http://enterprisesto.blogspot.com/2009/03/i-will-be-your-crmist-and-he-will-be.html

3. Not Engaging the Business People: this is an extension of the problem above.

4. Doing Only Technical Domain-Level Architecture: this is usually caused by 1.

5. Doing Current-State EA First: This is usually because people don't realise that most knowledge in a EA should accrete as by product of business as usual.

http://ea-in-anz.blogspot.com/2007/08/myth-of-heavy-weight-ea.html

6. The EA Group Does Most of the Architecting: This is result of 1 and 2.

7. Not Measuring and Not Communicating the Impact: This is failure to look at the communciations and governance issues (i.e. is a by-product of 9)

8. Architecting the 'Boxes' Only: This is really comes from 1 & 6.

9. Not Establishing Effective EA Governance Early: yes

10. Not Spending Enough Time on Communications: Communications is really part of the governance process

What price SITP data quality

2009-08-30T22:27:00.000-07:00

More lessons from CRM - CRM systems like SITP systems are largely oriented at making decisions (rather that supporting transactions) i.e. more shameless plagiarism (or learning from more mature disciplines as a I prefer to think of it as)

See the source reference here: http://www.computerworld.com/s/article/9135688/What_Price_CRM_Data_Quality_?source=CTWNLE_nlt_entsoft_2009-07-23

In an SITP the data does not have to be perfect to be useful. Many things can be just an approximation or can be missing altogether. So how do you decide where to make your data quality investment?

The first step is separate the data elements (objects and relationships and their properties) into three categories the ones that:
(1) must be there and must be correct to prevent corruption in external systems or misrepresentation of the business.
(2) should be correct for the SITO to work at all
(3) people have asked for to make decisions or record the state of the enterprise

A data quality analysis on each data element in the three categories can be scored based on questions such as:
- Ownership - Does it have an undisputed owner, or is it updated by specific roles as part of a formal business process, or can nearly anyone update it in an ad-hoc fashion.
- Validatity and auditability - Does it have validation on entry and does an audit trail track changes.
- Completeness and correctness - how complete is the source data, how much is missing, clearly incorrect, or duplicate.
Developing an understanding of this metadata is a 1st step that needs to be taken when looking at data preparation and loading.

Data element in an SITP system is in there because it was required to answer a specific business questions and/or because the SITP system is the source of record for this data.

Analysis will discover what data elements that are often missing or wrong. Depending on what concepts are being dealt with the data that is often found missing depends changes e.g.
- Business goals and strategies - will often lack: weighting and explicit relationships
- Applications - will often lack: a range of cost information, related standards and business processes
- Standards - will often lack: lifecycles, basis of current preferences, current and planned usage

Historically where there is no SITP solution it is difficult to collect some of the data in the first place, there are many ways for the meaning of the data to be misinterpreted or misrepresented, and there is often no easy way of usefully applying it (i.e. its recorded as academic exercise and not tested through the fire of use).

In many cases, you can't afford to spend too much on data quality before the system is implemented. What you need to understand is the metadata. If the business question needing this data is materially affected by the quality of this data you will need to carefully assess the cost of remediating the data with the impact and improvement in its quality with have on the decision that are being made base on it.

You can set business rules that allow you to determine when it's worth chasing a data element's quality and when it isn't.

It gets exponentially more expensive to improve data quality. If it costs $X to get solid data quality on 2/3rds of your records, it will probably cost $2X to get the data quality right on half of the remaining records, and $4X to get the half of what bis then left.

For most purposes it is hard to justify a lot of remediation on historical data, and one is better to invest the effort time in improving the way data is captured on an ongoing basis. In many cases it is sufficient to start capturing data on a forward on a JIT basis, or as data is used. Over a short space of time i.e. a year a two most of the data needed for SITP will accrete as natural by-product of improved processes (of course adapting the processes to capitalise on the SITP is a key step to enabling this).

EA Frameworks

2009-08-26T13:42:00.000-07:00

Everytime one looks at implementating solutions to support strategic IT planning, transformation, optimisations and governance one is asked one supports one or more of the common EA frameworks.

The use word "frameworks" gives a good insight to EA as a practice. Major EA frameworks (FEAF, DODAF, TOGAF, Zachman) mean different things by the terms (taxonomy, method, reference models, architectural styles) and have different roles.

In my experience people who ask about this seldom have a good grasp of the real questions - so I usually ask them to describe what they are trying to achieve. This usually provokes frustrated responses because they don't want they want to achieve they just want to follow the framework du jour.

It would perhaps be more acceptable to blythly follow these frameworks, if over more than a decade, they had proved widely successful.

[WIP]

EA-Emperor's new clothes - from Gartner

2009-08-11T18:08:00.000-07:00

According to this emergent architect item Gartner now claims - EAs must adopt a new style of enterprise architecture - 'emergent architecture', also known as middle-out EA and light EA, and set out definitions of the new approach. I see this as Gartner starting to slowly realise that they have long confused Enterprise and Solutions Architecture (doing neither constituency any good).

I would argue that what is now being advocated has always been best practice i.e.

Architect the lines, not the boxes i.e. the connections between different parts of the business rather than the actual parts of the business themselves. [this is why the focus SW developed oriented modelling and complex BP modelling/simulation has seldom made sense]
Models all relationships as interactions via some set of interfaces [obviously - which is why I have long argued for a decade that the venerated Zachman model needs another column i.e. on presentation/interfaces (user, system)]

And regarding the 7 "new" principles:

Non-deterministic - "they instead must decentralise decision-making". The term non-deterministic is a misnomer. What you really want is objective deterministic decision making carried out in a decentralised, objective and transparent way.
Autonomous actors - "EAs must now recognise the broader business ecosystem and devolve control to constituents". EAs have NEVER controlled all aspects of architecture. One is tempted to suggest EAs should also consider how they work with the IT ecosystem.
- Rule-bound actors - "EAs must now define a minimal set of rules and enable choice". EAs have NEVER provided detailed design specifications for all aspects of the EA (this is confusing Enterprise and Solution Architect)
Goal-oriented actors - "Each constituent acting in their own best interests". It is just silly to suggest anything else has ever really happened the real world.
Local Influences: "People are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No one has data about all of an emergent system. EA must increasingly coordinate". [Putting aside the absurd use of the word "Actor" in the original"]. Yawn - nothing new here. However one wonders if the use of the word "system" belies a recidivist tendancy towards again confusing Enterprise and Solutions Architecture]
Dynamic or Adaptive Systems: "System changes over time. EA must design emergent systems sense and respond to changes in their environment.". Again nothing new.
Resource-Constrained Environment: "emergence; rather, the scarcity of resources drives emergence". Necessity if the mother of invention [is over two thousands year old]

Nevertheless it is helpful to recognise that 5 of Gartners "new" points if restated are worth reiterating

Decentralised decision making needs to be facilitated (and therefore access to information) - so we need to make information available to people in many places (in a way that suits them)
Engaging with all constituencies is key - including the broader business ecosystem and devolve control to constituents (and of course the IT ecosystem)
Publishing rules (standards, patterns etc.) is critical - so we can let solutions architects, and specialised technical architects do their job.
Making decisions objectively and transparently is critical - as constituencies will always act in their own best interest - so we need to understand, and be able to examine/question, why different conclusions are reached.
Facilitating KM and collaboration if fundametal - rather than trying to control all the information, and create all the artefacts (or pretend that the knowledge can "live" in documentary artefacts).

Reference models - what examples exist in mature domains

2009-08-09T16:35:00.000-07:00

To gain an insight into reference models we can examine how more industry deal with reference models. I am looking at this through a very narrow lenst focusing on patterns for the built environment.

In Alexander's seminal work on Patterns he describes a set of patterns. Some of these patterns relate to each other. The patterns based on the physical size of what they apply to i.e. first come those applying to large areas (e.g. towns), then comes patterns relating to buildings, then to space in buildings (e.g. rooms), then patterns relating to elements within buildings (e.g. column details).

We could regard these as a reference model (RM) for design.

These patterns as a whole sit beside an extant set of reference models some of which are so well known that they hardly need articulation e.g. lists of:

types of space - rooms - a dwelling could have;
functions a dwelling could facilitate;
measures: structure, construction, lighting, acoustics etc.;

As well as beside reference models that are encapsulated within various regulations and laws, or by technologies

building best practice (codes)
products
safety and efficiency
etc.

Lastly we could consider the set of psychological and physiological requirements people have for a buildings:

warmth, quiet
peaceful, welcoming

The original work, while seminal, has several limitations resulting from a lack of semantic precision and the form of the work (a document). These are that:

it does not relate the patterns RM to other RMs requirements, space-types, functions, products etc. which as a set are the constraints reflect requirements and technologies.
the mode of presentation does allow one to automate the analyse of the use of patterns for referential of inferential integrity.

These limitations can be now be easily addressed with modern methods of managing reference models.

Perhaps in architectural domain they can be effectively dealt with be people (though looking at building one sometimes wondered). But I don't think this is true in some other increasingly complex domains where technology and expectations change too rapidly to allow best practice to encapsulated in documents, taught in a professional school, and reflected in regulations.

Common frameworks and reference models

2009-07-26T17:46:00.001-07:00

I believe what is neeeded is a consistent meta-framework for describing how information about an industry/sector and enterprise (federated or stand alone) is organised.

There have been a number of frameworks which may provide insights into what is required in a meta-framework - some are generic and some are industry specific.

Generic

Zachman framework - has two dimensional taxonomy with rows indicating different the views of different roles (business to technical) and columns indicating data, function, network, organisation, time and motivation
IFW - has a taxonomy and reference models. It is for analysing and structuring information. It is portrayed with 10 columns representing types of information (e.g. strategy, organisation, data, skills, functions, interfaces, network and platform - and either "workflow & solution" or "involved parties, products/ arrangements") and rows based on types of analysis (conceptual categories for analysing information, terms and terminology, principles for structuring different types of information, detailed designs that use information, how to implement these designs).

Industry specific frameworks (which could be called Industry Architectures - Cf. "Enterprise Architecture" include:

Government agencies - FEAF which has a set of reference models and a some methods for a applying them (particularly around alignment, investment planning and business case creation). The reference model set includes: Performance, Functions (BRM), Services (Applications), Data and Technology
Telecommunications - TM Forum's reference models for: process (eTOM), information (SID), and applications/services (TAM).
Hotel Industry - which I have not yet seen a published structure for.
Insurance - IAA which has business processes and activities, ACORD's eMerge (information exchange). IAA (IBM) is a sets of that trace out: information, data and component-architectural infrastructures and describe business objects and the components owning these objects. IAA contains a Business Model, Interface Design Model (components, interfaces and messages), Specification Framework (product definition and agreement administration), IIW (models creatimng data warehouses)
Health - Healix established a framework consisting of a set of reference models oriented at: strategy; policies and rules; function and process; information; components (applications and services).

The purpose of this entry is not to define the answer - but to outline some things to consider. See also:

http://enterprisesto.blogspot.com/2009/01/structure-for-thinking-about.html-
http://enterprisesto.blogspot.com/2009/01/introduction-to-reference-models.html

It is important to realise that IT industry as a whole has a lot to loose if a consistent way of deal with these issues arises - so one can expect opposition for the major incumbent/dominant vendors of IT products and IT services. This opposition is most likely come from activite participation in any groups attempting to establish standards i.e. embrace and smother (rather than the old fashioned FUD strategy which people are becoming resistent to).

The reason is for opposition is that standardised ways of doing things will allow many things to be demystified and commoditised i.e. reducing the amount can be charged for products or services as informed contestable selections becomes viable, and best practice becomes common and public.

Semantic precision and documents

2009-07-22T14:55:00.001-07:00

Modelling semantics provides all of the following: glossary, controlled vocabulary, data dictionary (objects, properties, visualisations), data model (relationships, cardinality, layouts), taxonomy (inheritance hierarchy, and domains), ontology (where URLs relate data).

When determining semantic precision one would assess if the representing is

correct: consistency of syntax and semantics
translatable: can it transformed ensuring semantic equivalence
analysable: can it be searched, queried and reasoned on. Can logic be applied, can it be "measured" directly or does the representation require intepretation.
integrateable: can they be related to other knowledge in other forms
complete: adequacy, expressivity, scope
extendable: is it difficult to define new concepts
concise: do they record things as efficiently as possible and their is no unintended duplication.

In these definitions we don't mean what a person can do through interpretation or inference i.e. perhaps someone looking at a picture can analyse it, integrate with other concepts they have etc., but a system or application can't.

When we are examining the utility of documents (e.g. Word, Powerpoint, Visio diagrams) - we can see that they are not a very good way of ensuring semantic precision. They don't ensure correctness, they are not easily translatable, intergratable, and they can not be analysed or reasoned on. They can be complete, though seldom are, and the form doesn't require completeness (e.g. there is no validation of cardinality). Likewise they are seldom concise. They are extendable.

Diagrams provide special problems. In some mature domains semiotics and iconography have matured so that images can convey semantics with some precision. Sadly when one looks at many Visio diagrams one find that they don't follow any precise semantics e.g. they don't have a controlled vocabulary and spatial concepts e.g. alignment, containment, proximity and connecting lines, don't have explicit meaning and are used inconsistently. This lack of precision means they can not easily be analysed, integrated, and often importantly translated.

People often seek to reuse the information in documents. This means they need to be able to be translated and integrated. It is often suggested that with some remediation (i.e. by a person) these documents can be made "correct", "complete" and "concise" so that this is viable. In practice it is almost always more efficient for a person to examine them and model them directly in some form that ensures semantic precision - rather than attempt to correct them, then translate them and then deal with any translation errors (or remaining incorrectness in the source). The very act of fixing them is more effort than the modelling.

The metamodel provides the modelling semantics in a central repository. A metamodel can consist of a set of metamodels each covering a different domain of interest. Processes are required to manage change (approval processes associated with the creation or changes) and ensure duplicate or redundant data elements are not introduced. This is more difficult than it appears as often multiple mechanisms are available for recording information e.g. a property of a person could be their last name, or their last name could be recorded as a relationship to a family.

I encounter problems with these issues every day when look at business or technology strategy, enterprise architecture, business analysis etc. The authors of the artefacts and a small clique that the authors have usually communicated with directly to explain things - don't see the problem - but everyone else who encounters the documents and tries to work with them finds problems resulting from semantic imprecision i.e. incorrect, incomplete, untranslatable, unanalysable, unintegratable and are not concise.

I would argue that is a major problem with current approaches to the adoption of business plans an strategies in particular i.e. when the foundation artefacts are semantically imprecise.

Lessons from the melt down

2009-07-21T22:35:00.000-07:00

I thought this a really useful real world example: http://www.infoworld.com/d/architecture/lesson-meltdown-listen-your-architects-806?source=IFWNLE_nlt_blogs_2009-07-20

Fighting the good fight, and losing the war - because internal internal competition militates against success.

Internecine inertia and the desire to avoid the identification of common-denominators - because the silos of activity are happy being silos.

Planner and architects see the benefit, but what did those within each department have to gain - compensation models don' reward enterprise players.

Large enterprise software vendors are complicit (IBM, Oracle, HP) i.e. the benefit in having things commodified (anything really). They want to lock you into a proprietary stack, even though it's impossible to adopt the same homogeneous stack across a very large

8 dirty little secrets of Enterprise Architecture and Strategic IT Planning

2009-07-13T20:40:00.000-07:00

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

An IBM view on EA

2009-06-30T16:05:00.000-07:00

The following is based on my analysis of:
- http://www.it-director.com/technology/sys_mgmt/content.php?cid=11379&page=1
- http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/bpmjournal/0812_jensen/SOA_BPM_EA.pdf

The following is what I understand IBM's position to be. Comments in square brackets [] are mine (not IBM's). It is amazing when one looks at IBM's position one can only conclude that the tooling they offer is unsuited to the purpose.

EA models defines a context in which may be elaborated in more detailed models e g. ER Diagramming, UML, BP Modeller etc. EA needs to understand processes [and presumably rules/policies, information, services, etc.] irrespective of how they are implemented (by what, who, where and how). EA information needs to be able to used to lead to technology implementations. In the integrated scenario Architecture Plans (in EA) are handed downstream, either between companies in the supply chain or within a single entity, to the Build team that continues putting meat on the bones with eye towards product development" [and presumably we must allow that these implementation will be done in technologies from a variety of vendors i.e. so we will need a open way of transition for EA to technology specific tools].

• EA is about "Architecture for Planning"
• EA provides the ability to clearly communication strategies and objectives to the entire organization; and records how technology assets are used to run an enterprise.
• EA's real value comes with the ability to investigate multiple future architecture scenarios and understanding the impacts to assets, organization and process before making the changes.
[so an ability to deal with Iniatives, Scenarios and multiple possible futures is key].
• Enterprise Architect deals in abstractions and things that are always changing, use a generalised tool and are comfortable with "knowing something about everything" vs. Solution Architects (designers) who deal in specialist areas (BPM, SOA etc.) and use specialised tools oriented at engineering design (UML modellers, ER modeller, etc.) and are only happy when knowing "everything about something".
• EA is about "doing the right things", BPM is about "doing things right".

EA, SOA, BPM and are all of value, using all three together can produce the most value. To succeed in you must
• 1st and foremost: establish a collaborative platform supporting the critical dynamic interaction across the enterprise. [presumably this requires many different ways of communication to many in the enterprise]
• have a holistic approach shared by all involved roles, tailored to the culture and environment
• establish awareness amongst key stakeholders across the organization, and particularly look at how to engage the with the business people [which typically not mean forcing them to at technical oriented abstractions of complex models. Rather they will want interfaces, views, reports and visualisations that address their issues and interests]
• think through the lifecycle and how to execute your architectural framework
• be specific about your objectives and have an explicit and accepted governance model, recognise this will often require significant cultural shifts to ensure buy-in to a shared effective process of decision making [so focusing on decision making early would make sense e.g. what questions to be answered]
• enable collaboration through good communication and a sharing of work products, based on a common language, with an understanding of and empathy for roles other than your own
[create artefacts,interfaces, views, reports and visualisations suited to the audience]
• enable integration between enterprise planning and solution delivery across all planes of architecture [using open standards to avoid lock-ins and ensure transparency]

IBM now has one real EA modelling tools - System Architect. Rhapsody is about "Architecture for Building" and is about model-based systems and software design and development. [There are many other tools in with more detailed orientations (SPARX) and one should not see these as EA tools]

On EA in Government - also see:
http://www.govtech.com/gt/articles/698252?id=698252&full=1&story_pg=2

CIOs perform a balancing act between the need for new technology versus the need to contain costs, security versus collaborative processes and accessible data versus the need for business with IT strategies. To achieve this they must close the gap between business and IT by becoming a business executive first and a technologist second. They need to build a hybrid skill set that enables IT professionals to understand the business's needs [and one would have thought communicating effectively with the business i.e. not using abstract technical languages and frameworks].

EA addresses this balancing of business and IT strategies when properly implemented:
- achieve stronger alignment between IT strategy and business goals;
- align various platforms and technologies that have resulted in excessive complexity and cost;
- implement IT standards and governance that enable greater technology efficiencies;
- improve performance, availability, scalability and management of existing architectures and applications;
- support new business processes with new technologies; and
- adopt reusable assets to drive greater efficiencies and faster time to market.

What is the cost maintaining the data we need for informed decision making

2009-06-24T19:33:00.000-07:00

I am often asked about the costs of maintain the information needed to make informed decisions.

I have recently got some facts from two different sources - one a bank in Australia and the second a large utility in Europe. Both are of similiar size.

It is difficult to get validated real world data on the broad range of information required (from business strategies, through business operations, through to technology). It may be that some things e.g. business goals and strategies may very little effort to maintain, however things have more properties, characteristics or relationships and may take more effort. Of course with many we can record them at different levels of detail from different perspectives (determined by the focus of our interest.)

Applications are potentially one of the more complicated things that data is captured about. Applications, or more accurately the services and user interfaces that applications provide, are also useful to consider as they are of interest to several parties e.g. business (whose function it is to achieve business results with the services and user interfaces) and technology (whose function it is to provide the services and user interfaces).

The two organisations both capture a few dozen key properties and relationships about they applications and both have similiar intended uses.

One of the organisations uses a strategic IT planning solutions that acts a single of truth for a wide range of business and technical stakeholders. They have calculated that maintaining a set of information they need about applications takes about 90minutes a year.

The other organisation has calculated the manual cost of creating an application inventory costs them 1-2 hours each application, each time it is done (in documents e.g. Word, Excel and Powerpoint). They also say that it is done many times a year to support to many initiatives and assessments (risk, regulatory, cost etc.) and by different parties. If we said that such an inventory is created just 3-4 times a year that would put the cost at 6-8 hours per year.

This reinforces my view that maintaining an enterprise architecture using the right class of solutions has a negative cost i.e. 1.5 hours per year, vs 6-8 hours per year in the case of the applications inventory.

Of course another strategy could be not to gather the information necessary for informed decision making - but few people openly advocate this.

The also ignores the fact that when this information is done in documents it is difficult or impossible to relate to other data, to analyse, to render in different visualisations.

When individualism becomes solipsism

2009-06-22T00:29:00.000-07:00

I have just listened for umpteenth time a person say that the way they current deal with the information (in some ratty little document or model that sits in isolation from other scrap of knowledge about the enterprise) suits them well.

Of course it suits them quite well

They created the document for a purpose. If it. If it didn't suit even them, for that purpose - that would really sad. The fact that it doesn't suit anyone else or any other purpose (in fact is probably to most other people most of the time) doesn't seem to have dawned on them.

It is unclear to me if they are unaware that other people exist, or if the idea that some of the knowledge in their documents could in fact be of use to someone else hasn't occurred to them.

What disturbs me most is that of these people claim to be "information" technology "professionals". So if they don't understand the need to manage information effectively what chance have we with others.

I hear:

IT people say it about their: interfaces, applications, servers, data etc.
Business people say it about their: capabilities, functions, policies
Strategists and planners say it about their: plans

Yes - they all realise that no one can answer a simple questions like: what projects affect this interface.

Changing the ways people manage and communicate

Fortunately in my calmer moments I recall the challenges I enountered in the past when trying to introduce new technologies e.g.
- email & word processing - I heard the same things in the 1970s
- computer mapping and CAD systems - I heard the same things in the 1980s
- IM and document management (Cf. Sharepoint, Wiki, Blogs etc.) - I heard the same thing in the 1990s
And now I hear it again.

Michael

Challenges to objectivity (getting typing pool to like email)

2009-06-21T21:20:00.000-07:00

I recall many years ago advocating the introduction of word processors and email in place of the old typing pool and mail delivery trolleys. Unsurprisingly a range of people were not too impressed e.g. those who:

sold contract typists or did typing as a service or
provided contractors/staff to push around the mail delivery trolleys (or the mail trolleys themselves or the typewriters)
the typing pool itself (usually an internal function) wasn't pleased.
the senior executives saw little benefit because they could justify having someone type their

letter and read their mail (and many middle managers aspired to be senior managers so by aspirational affinity - said they could see no benefit).

Many of these people genuinely, and understandably, struggled to be objective. Every conceivable excuse was postulated. As there was practical differentiation in many of the products and services (contract typists, type writers etc.) the vendors of these things were often successful due to the strength of their relationship with senior management. So their interests combined the disinterest of senior management presented powerful opposition.

Fortunately the CFO usually saw the benefit. Sadly the profileration of these document creation tools didn't do much to keep down paper consumption.

I see similar occurring now with the introduction of solutions that seek to provide true enterprise solutions to strategic IT planning, governance, architecture etc. Like email and word processing these systems involve a form disintermediation and democritisation i.e. the people who know record things (not have it recorded for them), and communication is by the people for the people.

These systems are often described as BI for IT, or ERP for IT. Fortunately the implementation of this next generation of tools should eliminate the need for many documents (and emails) and go some way to reduce the amount of paper that needs to be consumed.

Unsurprisingly some people are not too impressed e.g. getting "traditional" strategy, architecture consultants or teams interested in these solution is like trying to get the head of the typing pool (or the person who sells typists) to buy into word processors and email. Ironically the reason many of these people got into strategy and architecture was not to produce artefacts per se - but rather to think, to imagine, to synthesise, to concieve and these solutions would actually free from the drudgery of data collection and collation.

Many consultants working in this area are sadly conflicted and struggle to objectively see that while their self-interest is threatened the paradigm shift is essential.

EA covers a multitude of sins

2009-06-07T16:29:00.000-07:00

I am often asked to suggest the best approach (or solutions) for implementing enterprise architecture. The challenge with this is that people mean so many different things by it that it is hard to know what to suggest e.g.

Strategists - usually seek a strategic IT planning solution - they seek solutions that can engage with all constituencies and are focused on establishing a single source of truth. They seek the ability to integrate data from many sources (people and systems) and communicate with many people (visualisations, reports, models etc.). The challenge with this approach is that it can take a long time for the value of the knowledge base created to be visible.

Business oriented architects - usually seek solutions that manage the technology assets (costs, value, risk etc.) and enable a wide group of people to objectively participate in the management of the existing portfolios (services, applications, infrastructure, skills) and plan future investment. The risk with these approaches is undertaking each optimization activity as a stand alone or point in time exercise rather than establishing a systemic solution.

Governance oriented architects - usually seek solutions oriented at compliance with internal and external standards. They also realise that there are many roles and constituencies that need to be engaged (so technical and some not - in any area being considered). They many focus on the management of technical standards, preferred products, patterns etc. A key to the success is that the touch point processes are adapted so that governance is built into them, and feedback loops occur naturally i.e. that the approach is inclusive. The risk with this approach if it is implemented by itself is that it is seen just as barrier to change and initiative.

Framework oriented architects - seek solutions that implement the framework they have educated in or sold on. If the frameworks is oriented around investment planning and business cases based they seek business analysis and business case management for the enterprise (usually portal oriented interfaces with document production); if it is oriented around a set of reference models they seek support for the reference models and the ability to align their enterprise with the reference models; if it is oriented around a taxonomy they seek a predefined set of semantics and views; if it is oriented around a method (a set of steps) they seek a model or portal solution that steps them through the steps with wizard-like simplicity. The risk is that framework zealots focus on the frameworks for their own sake and don’t ground their efforts in terms of visible business value.

Aspect oriented architects - these people are focus on one aspect e.g. data oriented; service oriented; process oriented; object oriented; package oriented etc. and tend to see the needs as extensions to these domain e.g. oriented at data modelling; SOA; process modelling; UML modelling; modelling the capabilities of their preferred package (ERP, CRM etc.), etc.

Solutions oriented architects - often seek extended solutions architecture - what they seek are usually modelling tools for a group of architects to use to communicate principally amongst themselves - with some views created for other constituencies. They will often seek solution of engineering oriented languages and views. Experience shows that these modelling oriented approaches seldom produce sustainable value.

Value or mission oriented architects - are usually driven directly by a project or business imperatives e.g. reduce the cost of X by ...; reduce the time it takes us to do Y by ...; reduce the risks of Z by... . They probably have the best chance of concrete success as they by definition have SMART goals.

When pressed many will say they want all these things - but the solutions they select and how they go about the implementation reflect one or more these orientations. The emphasis on tools depending on how much people place weight on:
- establishing a sustainable enterprise assets (vs meetings the needs of single constituency) which involves strategies for ensuing data consistency, quality
- communicating with all key stakeholders e.g. engaging with them interactively and allow them to enquire
- integrating data from many sources (which requires support for semantics and integration mechanisms)
- modelling and presenting the various views and diagrams that have been produced (often manually) in the past.

Justifying the cost of solutions for strategic IT planning

2009-06-04T17:49:00.000-07:00

There are 4 common ways that investments decisions are made.

1/ Common sense e.g. this is how we justify the use of: Office, Email, Accounting systems etc. no one in their right mind would not use them. And this is in fact probably the soundest way to justify them i.e. connecting to specific ROI, or short term business outcomes is problematic and not that sensible i.e. perhaps the benefits are pervasive and manifold.
2/ Associate the business value to some current initiatives e.g. we want to save $X in IT cost/risk and to that we need to do by: doing some things (run some programmes); having some people (staff, consultants etc.) and using some suitable tooling.
3/ Try and create specific metrics that allow an ROI to calculated. The real challenge is usually that the quality of the current state analysis is so poor, that accurately slicing and dicing the costs is challenging (hence the reason for a better approach). And IT is good at burying the dead and excusing under delivery i.e. within 20% of budget, within 50% of time, and achieving 50% of original scope is regarded as a success.
4/ We have people who do this job - they need solutions that enable them to do it e.g. we write documents - we need a Word processor (not a type writer), we send messages - we need email (not a faster mail trolley), we do strategic IT planning - we need a strategic IT planning solutuin (not more Visio, Excel, Word and Powerpoint documents). See: Providing professional tools of trade.

ICT needs to get its own house in order

2009-04-01T21:26:00.000-07:00

ICT really needs to get its own house in order before suggesting to the business how it can help the business on business things (strategies, plans etc.).

I have just sat in a room of 50 EA's saying how EA needs to be driven by the business and the need to engage with the business i.e. go and talk to them. It is a sentiment I agree with in principle. Clearly all ICT strategy and architecture is for and about business - and should be driven by the business.

However usually these people have no credibility with the business - because the business doesn't see they as business people i.e. understanding fundamentally what business is about.

Like me, the business people suspect that these EA people can't usually answer fundamental questions about ICT (i.e. their business domain). They think it a little precipitous of the EA people to suggest to the business that they jump up and help the business proper - when getting their own house in order would usually be a better starting point (i.e. leading by example, and from a position or strength and knowledge).

Most large ICT organisations can't produce, maintain and analyse the basic information associated with the ICT domain they are meant to be managing (i.e. they don't manage their business). So what the business really thinks is
"how are they so brave - having failed in the business management of their domain - to suggest they can engage with the business about another domain (which they are not the domain experts in)?"

Ultimately managing things in any business is about managing things like people, assets, money and risks.

Usually EA's can't report on what is actually spent on ICT, how it is spent, why it is spent; how the spend can be reduced; how asset utilisation can be optimised etc. They can't demonstrate an understanding of ICT costs based on: asset/product type, location, vendor, class (product, people, service) etc or related to the services/offerings their business provides (except at the very highest and vaguest level). They can't link their ICT spend to the enterprise's income and mandated compliance needs at a level of detail that allows management to be effective i.e. what is the impact of this project not proceeding or this asset failing. They can't describe the major business functions, information, rules etc. their ICT systems implement (where and how).

This all requires a system (accessible to all, that supports reporting) and data gathering, and some hard work and thinking.

So having failed in one domain they are in fact responsible for - rather than doing the hard work to manage this domain (ICT as it increasingly gets more complex and less well undestood) they seem more inclined to redefine the domain rather than actually address the problems.

I can't help thinking it would make more sense to demonstrate excellence in the management of ICT before postulating the ability to engage with the business.

I will be your CRMist and he will be your ERPist

2009-03-24T21:58:00.000-07:00

People just don't seem to understand that enterprise architecture is about enterprises i.e. all the people with critical knowledge about how the enterprise operates sharing knowledge and using that knowledge to make decisions.

No one would stand up and say "I will be your CRMist" i.e. I will be the person who does CRM for your enterprise. Similiarly no one would stand up and say "I will be your ERP-ist" i.e. I will be the person who does ERP for your enterprise. Why - because it doesn't make sense.

What they could mean is that I will help establish a centre expertise for CRM (or ERP) within the organisations until the practice is so well bedded in, and a CoE is no longer required. Or I will champion the implementation of CRM or ERP systems - and the associated organisational change needed as we move from our manual systems.

Why then do people stand up and say "I will be your Enterprise Architect" - and expect to be taken seriously. If they quickly qualified this by saying they wanted to champion EA, or develop a CoE for EA - perhaps we could take it more seriously. What they could mean is that they will help establish a centre of expertise for EA within the organisations until the practice is so well bedded in, and a CoE is no longer required. Or I will champion the implementation of EA systems - and the associated organisational change needed as we move from our manual systems.

In fact the whole practice of EA i.e. the term itself has been undermined by the use of the term is in this "I will be EA" - it clearly isn't about collaboration, sharing knowledge and making decisions - because if it was the sentence wouldn't make sense. So EA must be something else - maybe it means Expensive Artist - I will produce pretty pictures of things using Visio.

Approaches need to be instantiated to be useful

2009-02-20T18:08:00.001-08:00

Introduction
Approaches need to be adapted to the environment in which they are to operate. The initial adaptation may be to an enterprise and the approach may be further adapted to specific units, uses or projects within an enterprise. Knowing how an approach should be adapted usually requires and understanding the principles underlying the approach and experience in applying the approach in a range of different circumstances.
Some approaches have a 1st step that is to undertake instantiation, so one could consider these generic approaches to produce results universally. The reality is that frequently the instantiation doesn’t really take place, often because the practitioners lack a sufficiently robust understanding of the principles and issues. This often results in attempts to follow a generic set of steps by rote.

Why care about approaches
Most knowledge oriented organisations want to achieve: quality results, continuous improvement and excellence of execution. Well defined approaches are critical to achieving these things. An approach ensures services are delivered in a consistent and repeatable way, and assists in classifying and collating knowledge (including in some cases artefacts).
Approaches are also used as a mechanism for reflect best practice (steps that are known to be required, techniques that work etc.). An approach may often involve best practices from several areas e.g. an approach to strategy & architecture may involve useful elements of a number of EA “frameworks”, elements of programme & project management disciplines, etc.

What do we mean by approaches
An approaches includes a process (a sequence of operations i.e. a set of steps), a set of tools and techniques, sets of constructs and artefacts (e.g. deliverables ), a number of roles. Approaches should:

be based on principles, patterns and exemplars so that they can be easily adapted (e.g. for organisations or projects).
be supported by appropriate tooling (systems, solutions, tools), semantics (language, notation, syntax and format) and associated techniques are key to the effective use of approaches that aim to deal with complexity.
provide an overview for experienced practitioners. It should not be xpected that anyone other than an experienced practitioner, or someone mentored by an experienced practitioner can successfully apply the approaches as attempts to obviate the need for the judgement are doomed to failure ).

Approaches can always be improved and we need to constantly assess approaches for gaps, areas of improvement etc.

What do we mean by experienced practioners
Experienced practioners are a critical to the successful implementation of approach. They stay abreast of industry and academic developments. They seen success and failures, both appling the approaches themselves and having supported others in applying them. Ideally they are open minded and realise that in immature disciplines in particular the various apparently divergent approaches being advocated by different groups may all have insights to offer. They are able to QA the results of an approach. And s a result of all of the above they are able to instantiate an approach.

What do we mean by an instantiated approach

Approaches need to be adapted to reflect many things including:

culture and language – both the social and organisational cultures (including of course regulatory and legislative environments), and the terms and terminology being used

size and nature of the organisation – clearly an approach suited to 1 person or a small team may differs from an approach suited to a large team, enterprise or sector

focus and orientation – approaches are often oriented at achieving set of goals and measures. The priorities (of the people seeking to apply the approach) and therefore how the approach should be applied varies. We could think of gross measures e.g. are we more focused on cost (to own, operate etc.), time (e.g. speed), risk avoidance (e.g. robustness, safety), etc. Clearly the approach to constructing road transport solutions differs in different circumstances e.g. formula one cars, urban transport, rural transport, fuel economy rallies etc.

tooling and technology – many approach are defined independent of the tooling and technology. This usually mean: the approach in generic terms (that may be hard to understand or ensure consistent application of the term), and that the approach may not take advantage of the features and benefits of classes of technology.

When an approaches has been instantiated we should have a succinct unambiguous set description of what needs to be done, by whom, how, where and when, using what etc.

Notes on terms
Approach - I prefer the term approach to the term method (or methodology).
Constructs - Systems, database, models, technologies etc.
Deliverables - A Miessian view of deliverables distinguishes work products (which are not delivered per se) from deliverables that are the final products delivered.
Exemplares - Examples are believed represent best practice
Approach overview - check lists, templates, exemplars, tips on techniques memory joggers etc.
Approaches with expertise - an approach is not a silver bullet

Strategy and architecture must enable action to be useful (e.g. transformation, optimisation)

2009-02-19T12:28:00.000-08:00

The purpose of strategy or architecture work is to either support a change or to manage risks. In either case for S&A work to be useful - it must enable decisions to be made that result in correct actions. The risks are often focused on regulatory and compliance issues (e.g. stay out of gaol, stay in business) and the changes often focused on outcomes (e.g. value, performance, profit etc.).

Too often S&A work is undertaken as a philosophical exercise - where the love of knowledge for its own sake seems to be objective. Sometimes it is used by sophists to support a pet project, technologies etc. In neither of these cases is it useful.

For many years I worked on projects. These projects all aimed to achieve transformations or optimisations (reduce cost, increase revenue, reduce risk, improve outcomes etc.). I think of "transformation and optimisation" (T&O) as long latinate words for shorter simpler English words "change and make better". There is much research that shows that large complex projects are seldom well delivered. There is also good research that indicates that the fundamental issues are the failure to deal effectively with complexity (e.g. complexity in the organisations, complexity in the task sets, complexity in the technologies or materials).

My focus on Strategy was based on a belief that successful T&O projects required better approaches to knowledge management and business decision making. These approaches need to deal with the complexity of the issues, the multiplicity of stakeholders, the nature of the enterprises involved.

This is one of the reasons I have called my venture ESTO i.e. to acronymically preface the goal (TO) with the key enabler (ES). There are other reasons for ESTO - that I won't go into here.

Enterprise Architecture can't be done by Enterprise Architects (it needs to be done by the Enterprise)

2009-02-09T17:19:00.001-08:00

Enterprise Architects keep wondering why their Enterprise Architecture initiatives fail.

They find all sorts of people to blame e.g. internal sponsor, business units (autonomy), vendors, economy, etc.

The real reason they fail is that in most cases the Architects fail to lead and coach the Enterprise so that the Enterprise can record, develop, extend and analyse how and why it operates (including its use of technology). Rather they attempt to do the Architecture for the Enterprise (or get consultants in to do it).

It is a little like employing someone to diet or get fit for you. It is unlikely to change you (or the Enterprise) unless you (or the Enterprise) does it.

What does it take to be good at Strategy and Architecture

2009-02-08T21:21:00.001-08:00

What is required for you to be good at something e.g. strategy and architecture.

I think there are at least 5 things that you need:

aptitude - S&A requires an innate ability to see patterns, form abstractions or generalised cases (organise, classify), to think laterally. Aptitude can't be easily taught. In most arts a key thing is the ability to accurately perceive.
experience - S&A both rely to some extent on a mix of wisdom and common sense. Common sense seems to be quite uncommon, but as one makes mistakes - if one pays attention, one can acquire it. Perhaps the understanding below could be considered to be covered under the heading of experience - but I mean experience in a far broader sense. It involves learning a multiplicity of disciplines and life skills. Experience is also something that can't easily be taught (despite what MBAs may suggest) - some things needs to be experienced. It is what help tell you that something doesn't feel right even if you can't articulate for the time being why.
understanding the environment and technologies - S&A in any field needs to be cognisant of the realities of what can be achieved in the environment in question using the materials available. This can be learned. It may take a while to internalise it depending on the domain but if you don't know you can usually rely on the expert advice.
understanding the tools and techniques - S&A needs to be done using tools, methods and techniques actually orient at the type of S&A you wish to do (e.g. those suited to collecting information from the audience and communicating to the audience). This can be learned - and it doesn't usually take the long.
willingness to keep learning and keep thinking - to reinvent, to reconceive, to question.

My current focus is enterprise strategy and architecture. But my original focus was building architecture and design. Anyone who has seen good architecture knows the architect needed:

aptitude - and I would content it is clear to anyone in any school of art or architecture that some people have talent and others don't.
experience - I was always told and now believe that architects don't reach maturity until they are at least 40.
understanding the environment and technologies - sadly some architects keep forgetting the need for this (and left to their own devices produce building that leak, fall down, can't be built, or excessively expensive etc.).
understanding the tools and techniques - architects have developed over hundreds of years sets of artefacts to the communication they require (plans, elevations, sections, details, specifications etc.). More recently over a few decades they have translated these techniques into CAD and come up with new ways to communicate (animations, simulators of various kinds etc.)
willingness to keep learning and keep thinking - few can imagine a successful architect that doesn't have this trait. Nor a good town planner that lacks it.

When I realised IT was a fashion industry

2009-02-08T15:36:00.000-08:00

When I realized with horror I was working in a fashion industry called IT
I first worked with a partially object oriented (OO) system in early 1980s. In the early 1990s I met a sage old Welshman who taught me how OO could be applied to the solicitation, analysis and recording of business requirements. He had a sound method and language for doing this that was very effective with business people, and that provided useful information for technology oriented people such as developers. Then a number of the more popular methodists sold their souls to a commercial venture and the focus of OO analysis was irrevocably re-centred on approaches ill-suited to business users. My Welsh OO mentor treated this with surprising equanimity and said “well of course we are in a fashion industry".

fashion – a vogue or trend, a prevailing mode imposed or favoured by those whose lead is accepted; attention to the latest trends, something in popular favour

I immediately bristled at this. I had always regarded IT was an engineering discipline (scientific, methodical, logical etc.). Over time I realised that I was living in the past.
When I learned programming at school in the mid 1970s it was taught by our mathematics tutor. At University the IT department existed within the mathematics department, and was lead by people who focused on logic and numeric methods. Most of the people with an interest in computing had developed the interest as it was necessary for their scientific discipline e.g. from nuclear physics to acoustics.
I had pretensions of being an artist, and instead majored in architecture. I lived for years with a fashion designer (and experienced the opening of boutiques, the emergence of collections, etc.). So I thought I could distinguish between science, art and fashion.
I didn’t have much time for the fashion industry i.e. how anyone could take seriously "yellow is in this season". What does it mean? It means that everyone has enough of the blue-stuff we sold last year, so to sell more we need to convince them blue is no good, and thry have to buy our new yellow-stuff. Or that blue-stuff always looked awful and we only just realized it. To me fashion at worst a sophisticated form of deceit; and at best played on human weakness, gullability and insecurity (the need to follow the flock), and in the process promoted gratuitous and wasteful consumption.

So when someone suggested IT was a fashion industry, I took offense. When I calmed down I realised that he was right. Much of IT had moved from being something like a science, or an engineering discipline to a fashion industry. Where something is in season - and things that were perfectly good last season are now eschewed for no real technical rhyme nor reason.

Fashion industries need to make people believe that what they own (or know) is no longer acceptable so they feel compelled to buy some new thing that has been produced (or conceived of). Marketing people in the USA in the 50-60s sought to change the appearance of car models each year (despite the negative impact on cost and reliability, and the unnecessary engineering, etc.). Of course this cancerous influence on the car companies will likely lead to their demise.
Fashion being prominent when utility is easily achieved and the rate of technological innovation is low (shoes, clothes etc.). I think it is inappropriate in an industry such as IT where there is so much still to be achieved and where real innovation continues at such pace (and I think it remains inappropriate in the global car industry).
Once people bought accounting systems now everyone needs an “Enterprise Resource Planning” system. Preferably one designed for a major manufacturer and advocated by a fashioable “independent” consultant. Perhaps people can’t justifying paying so much for accounting systems?

An enterprise PC’s main legitimate use is to: access enterprise systems, some word processing, work on a few spreadsheets, and enable email and Web browsing. As these requirements haven’t really changed what drives the upgrade cycle i.e. the adoption of new software and worse still new document standards, which in turn drive the neeed for new hardware and configuration services?

It is miracle of modern marketing that someone managed to make people care about an operating system (OS). Almost every significant electrical device has an OA (or several of them in a multiprocessor system like a car). Yet in with no other electrical appliance from an iPod, to a phone, to a game systems to a VCR to car does the average person really know the name of the OS, or care about it, nor would they dream of upgrading them (and this is in fact how it should be).

There may be nothing wrong with indulging an interest in fashion e.g. for clothes, cars or technology, if you do so with your money. At least in this item I won’t say fashion per se is bad, but it is an indulgence. The same is not trued if you do it with other people’s money, and pretend it is driven by necessity.

Vendors of course drive fashion industries so they can sell things. That is their role, hence the name “vendor”. The real problem however is not the vendors. Part of the problem is the people who know (or at least are paid to know) there isn’t a real reason to discard old technologies, or methods – and are spending other people’s money. Most of all it is the consultants and professional prognosticators (those whose lead is accepted ”, who need to lift their game – and tell the truth about IT’s dirty little secret.

In others item I write further about the adverse impact fashion on: design; development methods; analysis; etc. For now I will leave you with a quote:

I could discern omens of nothing newer than the old fate
of the sequacious: to be for ever at the mercy of the
exploiting proclivities of the bold and buccaneering in
their bullying and greed.
[Prelude to Waking, by Miles Franklin, 1950]

Technology perspectives driven by vendors, fashion and ignorance

2009-01-26T16:49:00.000-08:00

Prompted by more maddening items on orientation

Firstly let me say that I believe the following perspectives should be considered as 1st order when looking at ICT systems:
- presentation (from services i.e. they are by definition presented, to interfaces)
- information (from knowledge to data)
- process (from a capabilitity, to a function, to a process, worflow, to step/activity)
- rules (from a law, to a policy, to a rule, to a decision and control mechanism)
- characteristics (from being cool, sexy to what some might call non-functional requirements)
- organisation (from culture, to organisation, to role, to people).
- location (from country, to region to specific location)

Key 2nd order elements are:
- components (from products to objects) which can often be consider assets

I would also think that technologies (products and standards) are used by the vendor community (products and consulting vendors) to drive an feeding frenzy in some new (actually not new) area each year or so - so that some new set of things can be sold.

Orientations over the decades:

Information - When I 1st learned to programme the focus was on memory management and jumps in assembly langauges (there was no focus on presentation).
Rules - Then it was on logic and alogrithims e.g. Fortran, Algol, SNOBOL, LISP (oriented around Formulas, Algorithms, rules for processing strings, rules for processing lists).
Integrated - For a while real applications were then written in langauges that considered logic (presentation was fixed by the very limited range/type of devices; location/organisation/characteristics were effectively fixed by the integrated OS/HW). This was actually quite a productive time.
Information - Databases emerged and information engineering became king. Everyone forgot about function points because all you needed as information model (not).
Integrated - Then it moved to OO (and data and logic don't exist discretely). Unfortunately the methods were usually oriented at coders not business people.
Process - BPR lead to a brief fling with business process orientation, but it was really just a way the consultants to pack as many graduates as possible into organisations so they could document what was alreading known. In the course of this "Imaging" vendors became "workflow" vendors, before coming "BP vendors" and of course now they are "SOA" vendors.
Presentation - now with SOA we can focus on another set of technical standards and products.

Sooner or latter surely people will realise that all these perspective need to be considered (i.e.
presentation, information, process, rules and characteristics) and they stop throwing the baby out with the bath water.

An introduction to reference models

2009-01-21T14:55:00.001-08:00

An introduction to reference models. Models are ways of organised information so it can be used to answer questions. Reference models provide a consistent (and often best practice) way of organising information about something. They may be used a categorisation structure or they may be considered high level elements that are decomposed into more detail.

Determinants - few integrated sets of these exist in the public domain. Ideally one would have things such as: Legalislative and regulatory RM (LRM)

Enterprise strategy - RMs covering: goals, strategies, measures etc. some example include: FEAF's PRM (Performance RM) and one would ideally also have a Goals RM.

Enterprise operations - RMs covering: products, services, functions and processes, information and data, policies and rules, organisation structures and locations. Some examples include: NGOSS's eTOM, SID, FEAF's BRM) etc. So one would have: Functional RM (FRM), Rules and Policy RM (RRM), Information RM (IRM), Organisational RM (ORM), Services/Products (SRM).

Systems and facilities - RMs covering: systems and facilities performance (e.g. SLA templates, technology goals/principles). Some examples include service and application RMs: FEAF's SRM, NGOSS's TAM), Technology RMs: FEAF's TRM, TOGAF's TRM. The connection of these internally may be between the SRM and the functional modules/services associated with specific suites or services.

Suppliers - Some examples include: sector classification schemes; channel models; agreement topics (contract templates). This would include a Vendor and products RM (VRM)

The RMs should:
- connect within each level and between each touching levels.
- connect to detailed extant views of the enterprise e.g. the FRM may connect to existing detailed process models, the IRM may connect to data models, the PRM may connect to existing KPIs, etc.
- allow direct impact analysis to be undertaken
- allow inferential analysis to be undertaken (I will discuss this in latter entries).
- be treated a set and applied

RMs are:

Most useful when analysable - whenf they are related so as to allow impact analysis (both between domains, and within domains). Unfortunately many are often presented diagrammatically (great for communication, hopeless for analysis) or represented using inconsistent semantics, modelling paradigms that can't be related, or using arcane technology terms that are not meaningful to 99% of the world (e.g. use case, actor, cardinality etc.)
Not a silver bullet - but there is little doubt that using reference will often accelerate thinking and reduce the scope for oversight. However the value of this should not be underestimated. For many large organisations it may take a team or 1/2 people working for a year or so part time to come up with the above. More often than not they never complete anything useful.
Need to be tailored and used carefully - as with all things that represent purported best practice they need to instantiated in-situ (using experience and judgement) to produce something that is useful in the specific set of circumstances.
Need to be analysable from the top (and bottom) - this is why absence of Determinants RMs is so limiting as ideally these would allow one to relate the circumstances to the strategy, and then from that the strategy to the operations; and the suppliers to the systems and facilities. It is why compliance issues seem so hard (and produce such a good feeding frenzy for consultants).

A structure for thinking about enterprises

2009-01-21T13:02:00.000-08:00

A structure for thinking about enterprises

Determinants - externalities that determine what a business does, how it operates etc. These are external factors that include: cultural and social, market and competitive, legal and regulatory, etc.

Enterprise strategy - business: vision, mission, goals, strategies and plans (product, market, organisation), cases, governance and compliance, measures etc

Enterprise operations - business: services, processes, rules, information (objects, documents, data etc.), organisation, facilities etc. and change iniatives

Systems and facilities - including applications and services, technologies and system services, facilities and internal utilities. The systems area can be further divided into business services and systems and technology services and systems.

Suppliers - externalities that determine the products, services, standards a business can use e.g. technology products, services and standards; product channels; real estate and facilities. This section includes details of all provisioning and agreements.

Effectively the external constraints are the determinants and the suppliers; the goals come from the strategy and the operations, systems and facilities - represent a solution set (i.e. designed to the meet the goals based on the constraints).

Notes on the above

I have tried to avoid using two loaded terms in the above "architecture" and "framework". I use Enterprise to encompasses things that may not be "businesses" per se.
In each of the middle three areas there may be change initiatives (for transformation or optimisation driven from that level).
Business requirements derive largely from the Enterprise Strategy and Enterprise Operations.
User acceptance is the confirmation that the Systems and Facilities meet the Requirements i.e. represents a boundary condition and/or illustrates compliance with a set of constraints (e.g. requirements).
The division into into business services and systems and technology services and systems may be increasingly hard to work with in a way that is useful for decision making for most enterprises e.g. splitting a GPS function used by a business into its: application, infrastructure (device) and service (e.g. satellite) components may in practice be difficult. This will increasingly be the case as consumer and external services and components are integrated to support Enterprise operations. Similiarly in the past some technology reference models have identified somewhat layers of technology that are increasingly irrelevant in practice with many devices e.g. operating systems, graphics presentation, file and database, etc. are not that useful if the device is an appliance. These division are probably useful distinctions for technologies operated internally by an enterprise. But a decision is 1st required that operating these technologies internal is to be desired or required.