Enterprise Architecture in ANZ

Separating the data and the form of representation (models)

2008-08-07T09:32:00.007+10:00

(based on recent discussion with clients looking at how to operationalise an EA model in an enterprise context)

For a solution to work in an enterprise context it is important to be able to separate the enterprise data from models which references the data. This is for two reasons – the nature of models and nature of organisations.

Models - Models are very useful particularly for design and planning (where often visual representations are very powerful). The way something is modelled depends almost entirely on the purpose of the model i.e. what you expect to learn from the model. Models consist of data elements related in fairly complex ways (object, properties, relationships between objects, calculated values etc,). As models are always designed to achieve a purpose i.e. no one model can achieve all purposes – so data-elements will usually exist in many models (each model with a different purpose).

Organisations - In an enterprise many people will be interested in things from many different perspectives (economic, operations, organisation, product, market, contracts, etc.) and at different times (now, next year, in the future). Usually most individuals while having a broad interest in many aspects on an enterprise only have a detailed interest in, and definitive knowledge of, the specific subset of the enterprise they are focused on. So while many people may be interested in the services an enterprise provides some will be interested in these at purely a business level and others interested in the technical aspects, some will be interested in costs associated with a service, some with how the service is delivered (procedures, policies, information), some more with who/what performs the service, some with what agreements are associated with the services. So while many people may be interested in the service – few people will have definitive knowledge about all aspects.

Often the data-elements may first be considered, and captured in a structured and semantically explicit way e.g. when something is being conceived of, planned or being changed. Obviously while the model suits this initial purpose (design, planning) the data-elements will be reused latter in different ways i.e. other models, reports etc. Eventually when things are operationalised the data-elements will be updated by different groups with different interests.

Therefore the model form (which relates to its purpose, and the modellers specific design or implementation) will militate against most people (other than the author or designer of the model), interacting with the underlying data-elements e.g. updating data associated a service object type. It is not that most people are not able to understand the model if it is explained to them – it is that they don’t want to understand a model created for a purpose different to the purpose they have (i.e. they don’t want to invest the time and energy learning about data and relationships that are, from their perspective, extraneous).

So for most people, only interested in a small subset of the data contained in most complex models, the model will be too complex for them to grasp, or contain too much extraneous data (i.e. it just seems like complex monolithic assemblage of data not necessarily well suited to harvesting the data for reuse). This is especially the case if the people are not modellers by nature and or don't use the modelling tool/technology employed.

Therefore it is important that people have other mechanisms for updating the data-elements that will be represented in a model. Ways that suit their interest and their level of understanding.

Focus on EA is inversely proportional to the need for EA

2008-07-24T15:05:00.004+10:00

Focus on EA seems inversely proportional to the need for EA.

The potential value that enterprise modelling and knowledge management (EMKM) can brings to decision making is dependent on the size of the enterprise, the complexity of the enterprise and the rate of change.

If the enterprise is very small e.g. a couple of people the knowledge that exists is held in a few heads (often one or two). If the enterprise is very simple the knowledge can be held in a few heads. However for most large enterprises the knowledge actually resides with many people.

If the rate of change is very slow one has the time to try and slowly bring together the knowledge from the many people e.g. and produce a 5 year planning (or perhaps an annual plan). Communist states 5 years plans demonstrated that this method of planning doesn't respond well to rapid change.

The actual value that EMKM brings to decision making is a function of the scope and range of use. The function is probably a product function (rather than a sum function). The range of use can be considered to be the percentage of the people in the enterprise with knowledge who contribute. The scope of use can be considered to be breadth of the areas of topics of use.

The problem that occurs in large complex organisations is that they develop bureaucracies and silos.

EMKM for decision making is only required if there is to be change. If the status quo is to remain few decisions are required.

An instance of a bureaucracy is an organism and like any organism it seeks self preservation. Change could jeopardize the particular instance of a bureaucracy e.g. make it unfit for purpose. So change is in general to be avoided by a bureaucracy – unless the bureaucracy changes itself 1st to suit the future state. Unfortunately this is usually slow for real world change. As knowledge is power when it comes to decision making - the bureaucracy wants to have that power i.e. retain the knowledge. So a bureaucracy doesn't want knowledge to exist independent of the bureaucracy. Fortunately for the bureaucracy large organisations tend to be hierarchically structured with increasingly specialized functions – which effectively form silos of knowledge. These silos can easily be kept isolated if documents are used to retain as much knowledge as possible (e.g. powerpoints, word documents etc.).

Now if there is a slow of range – then people have the time to think, to consider things, including how to better manage the knowledge they need to make decisions. If on the other hard the rate of change is high – people have an imperative to act – and they don’t have the time to think about how to make better decisions. They need to decide what to do immediately.

So we can see that the organisations that most need EMKM – large, complex with high rates of change are precisely those organisations who will resist better approaches to EMKM.

Where there is little need for EA because things are fairly static - there is a reasonable focus on it (because key people have time to think). Where there is a great for EA because there is a lot of change being envisaged (growth or shrinkage, investment or divestment, risks) there is no time for it because people just want to act.

EA as a profession

2008-06-18T07:40:00.004+10:00

(prompted by discussions of ethics)

Many people claim to be IT professionals. Most Enterprise Architects I have met see themselves as IT professionals. It always makes me wonder what they mean by the word professional.

The word comes from "profession" in the sense of a public declaration, such as an oath -- so the word had an ethical sense from the start. In most of the traditional professions this was intended as a guarantee that the professional (priest, lawyer, doctor, etc.) would act according to a code of ethics and provide advice consistent with that code, rather than whatever was best suited their self-interest or misrepresenting the truth to suit a paymaster.

It seems that people now use the word in several different ways now, for example:

People, such as athletes and sex workers, who get paid for what is normally a pastime and no particular ethical sense is implied. In the former case gamesmanship replaces sportmanship (winning is more important than honest effort); in the latter play acting replaces genuine passion.
Profession to a code of ethics, such as medicine, law, or architecture, where there remains an ethical sense of someone who professes to the code.
Being a member of a professional body: this implies a level of training (e.g. academic), a set of recognised approaches or methods, and a professed set of standards that are adhered to. This is the sense more commonly used in trades.

The problem in IT is that people are never very clear on what they mean by the word professional.

Many EA's would recognise a common body of recognised practice, and many when questioned know what they should be doing, and how they should be advising people - though they don't bother offering this advice (because they know it won't be well received). They are often asked to do things they know doesn't make sense (suiting a paymaster's goals e.g. political, personal, immediate, rather than doing what makes sense for the enterprise or the long term) and they do what they know to be poor practice (wrong methods, wrong tools, wrong skill sets, wrong focus, etc.). This is a challenge that needs to be addressed.

See: Justifying EA

Architects need professional tools of trade.

2008-05-07T11:10:00.006+10:00

Why is it that people are quite happy to have architects, strategists, etc. who will typically cost them in-excess of $500k over 3 years. Get them doing "architecture" and arm with with substandard tooling.

Any cursory analysis would show only a small improvement in productivity and efficiency (5%) would produce a substantially better return of this $500k investment.

No one would suggest an accountant should be expected to do without an accounting system (server based solution) and a spreadsheet (numeric modelling and design tool). No one would surely suggest a project manager - should have a project planning tool. Why then do people arm architects and strategists with tools manifested unsuited to the needs of the enterprise and then marvel at their failure.

When one suggests that a suitable class of tools is used one is often tarred with the brush of promoting a particular product. Yet if an accounting professional suggested a suitable class of tools (e.g. spreadsheet and accounting systems are required for this work) the statement would be taken at face value.

Of course what does not help is "professionals" in this area asserting that EA can be effective when the right class of tooling is not used (despite decades of evidence to the contrary).

See also:
http://ea-in-anz.blogspot.com/2008/05/ea-knowledge-bases-need-to-be-active.html
http://ea-in-anz.blogspot.com/2008/04/what-we-learned-about-ea.html
http://ea-in-anz.blogspot.com/2008/04/what-we-sought-in-tool-for.html
http://ea-in-anz.blogspot.com/2007/09/why-dont-most-it-processes-work-well.html
http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html
http://ea-in-anz.blogspot.com/2007/08/myth-of-heavy-weight-ea.html

EA knowledge bases need to be active

2008-05-07T10:24:00.004+10:00

(prompted by people using old approaches with new tools)

The idea of publishing data in a static format is counter to the efficacy of EA.

What one wants in EA is to allow the ownership of the data to remain where it currently resides (i.e. associated with what business function, role currently owns it) - and to be able to see and analyse aggregations of the data (i.e. the data that represents the enterprise).

People should be able to update the data as a natural by product of their day to day work (function, role etc.). As almost everyone in an organisation is responsible for (i.e. owns) some data - this means that eventually almost everyone should be able to update some aspect of the data i.e. the function of maintaining the data is progressively distributed and decentralised (obviously this requires access management, data integrity policies etc.).

This is true of most other enterprise solutions (i.e. all users can update some things, and many things they just reference)

Actually typically people already do update some aspect of this data (i.e. update of the EA is already distributed and decentralised) - usually in a plethora of disconnected and unstructured documents (that suit each individual) but nothing for the enterprise (or the others in the enterprise) . Much of it would be in documents such as: business cases (applications, systems, business processes/products and services, business goals and strategies etc.), operational and procedural documents (holding roles, business processes, rules, products and services etc.), systems diagrams (applications, technology infrastructures), definitions of bodies of work e.g. project charters, statements of work, technical design documents, SLAs, BCP and DR documents etc.

The idea of publishing implicitly involves an unnecessary and function i.e. someone/something has to "publish" it. Where as in fact it should live (active data). The old model is like someone writing the encyclopaedia Britannica and "publishing" it. This just doesn't typically work for EA (it involves rework, it is too slow, the owner can quickly update or correct data, it is counter to the actual process of operating the enterprise).

Having said this in the initial stages of establishing an EA (perhaps much of the 1st year). It is reasonable that some people with a particular interest in a set of data central to many things e.g. business functions, application services etc. may establish a base of data, and some ways of organising the data, to make it easier for everyone else to collaborate.

Using an active EA as if it was is as static EA - is like using a nail gun as if it were a hammer (and then wondering why it takes so long to nail in the nails, and noting that a nail gun costs more than a hammer).

What we learned about EA implementations

2008-04-29T11:02:00.006+10:00

(based on many people asking why I recommend the implementation approach I do)

The fact is that most EA implementations fail i.e. they fail to produce sustainable value and a useful asset i.e. one that can be used to: answer questions (e.g. impact analysis), maintain knowledge, support business operations and business change, etc. Over almost two decades I have seen dozens fail (often undertaken by some of the brightes, most able, and most diligent people I have met).

I have seen EA initiatives in many types of organisations (forestry, health, insurance, government, finance, health and safety, eCommerce, retail, education, telecommunications, etc) and using many different generic frameworks and methods (e.g. Zachman, TOGAF, etc.) - and the quality of the result does not seem to be associated with either the type of organisation or which of these generic approaches is used.

It is true that in many cases inadequate tooling is the root cause, and EA "consultants", "experts" are quite happy to continue using office documents and essentially manual approaches because for service companies it is far more profitable to do the fishing, than sell a rod and teach the person how to fish for themselves.

Where poor tooling is not the cause what I usually have seen is work on an EA implementation commence:

lead by people who only understand about 10-15% of what the technology being used can do (and have a partial understanding of its intended use) or lead by people who understand the tooling reasonably well but who have very limited domain expertise (i.e. in enterprise architecture, ICT strategy, business/IT transformation etc.).
without a clear understanding of what is sought (requirements)
without a clear understanding of how the solution will be implemented (all the components, how design will be undertaken, how operational procedures will be defined etc.)
without a well defined (tried and tested) implementation plan
without an understanding of the organisations change impedence issues (the organisational behaviours that impede change) associated with improving touchpoint processes and roles.

Unsurprisingly these implementations seldom proceed well and usually erroneous conclusions drawn from what is delivered (from those who "don't get it" or sometimes "don't want to get it").

If one doesn't start with a clear view of the outcomes being sought - it is unlikely the benefits will effectively be achieved (i.e. if you don't understand the requirements it is unlikely the solution you will deliver something that achieves them).

Therefore what is required upfront is a focus on what outcomes should be sought, i.e.

who are the stakeholders and/or beneficiaries ?
what are the scenarios of use they have ?
what are the business questions they need answered ?
and in roughly what stage of an implementation ?

Some EA approaches aim to achieve this but they are so generic (i.e. they don't make an assumption that suitable tooling will be used) so they can't be precise enough about the nature of the requirements captured, or how the design will proceed.

This is why we have developed a detailed implementation approach. This defines all the major areas of work, the key roles, logical milestones etc. that is specific to the implementation technology we use and can be instantiated quickly for a specific project

People often think that there must be a single detailed approach to developing an EA that will suit every organisation. There is a common meta-approach - but the detailed approaches differs based on the organisation and the goal. The problem is that different organisations are focused on making different types of changes e.g. new products or new geographies, mergers, risk reductions (including regulatory compliance, DR, BCP), cost reduction etc. so their focus is naturally different e.g. I have seen EA implementations with many different orientations e.g.

Business and/or technology strategy (usually aiming at getting an explicit consensus as to what changes should be initiated and why).
Business process redesign (adjusting the way the business operates, as a precursor to looking at technology changes)
Application architecture (usually focusing on rationalisation, as a result of merger of unmanaged proliferation)
Service architecture (usually focusing on developing approaches for service governance)
Integration architecture (often now related to SOA initiatives, but in the past oriented around ESB, EAI initiatives).
Security architecture (unfortunately usually as an after thought).
Meta data and data architecture (unfortunately usually disconnected from the processes the data exists to support)
Rules architecture (usually oriented at understanding how strategies and policies are implemented in processes, procedures and systems)
Technology platform architecture (usually focused on getting better utilisation from servers, and/or planning for building extra server capacity)
Storage architecture (usually focused on preparing for the addition of extra storage capacity).
Standards management (usually oriented at governance)
Programme management (usually oriented at understanding how a set of capital initiatives, or business change initiatives relate to how the business seeks to operate in future).
Service level management (usually oriented at SLA templates, contracts and delivery exception management)
New product or channel definition (usually products that involve systems at the heart of their delivery)
Disaster recovery planning (usually leveraging off existing information about processes, applications, platforms and teams)
Business continuity planning (as for DR planning)
Requirements management (in the context of how the business seeks to operate)
Package implementation management (usually focusing on understanding how business operates, and how this relates to the package in question - so either the package can be changed or the business can change how it does things (or both).
Compliance management (understanding how regulatory or legislative compliance is being achieved)
IT Skills management (understanding what skills are required for what systems, usually to allow rationalisation or as a risk management exercise).

If one looks around an IT organisations one will see information about all of the above being created, collected, used and disposed of (whether that is intent or not). It is usually presented in a diverse set of office documents (business plans, business cases, project charters/statements of work, technology documents, software design documents and models, infrastructure design documents and models, contracts, requirements documents, business continuity planning documents). This suits each person producing the specific artefact admirably and keeps lots of staff and consultants employed. To change this situation take time and needs to be done incrementally and with purpose.

Often when you ask an organisation what they want to focus on they will say: applications, infrastructures (servers, storage, intregration) etc. but be unclear about how they will make intelligent decisions about these things without understanding: business/technology strategy, products/services, and the business processes, information, rules, organisations etc. that these solutions are designed to support. Or you will get organisations that say they want to focus on all the above - but struggle to work out what will the initial focus should be so that the stakeholders with greatest immediate need will be provided answers to the burning questions they have, while knowledge is gathered and organised in such a way that it is reusable in down stream phases to answer questions that are currently of secondary or tertiary importance (or not even thought of).

The art of a successful implementation is prioritising - based on a complete understanding of what the tooling can do, a good understanding of EA best practice and clear understanding of what the organisations current goals and challenges are.

What we sought in a tool for business/technology transformation and EA

2008-04-29T10:06:00.007+10:00

(based on many people asking what the requirements are for a tool)

People often ask me what lead us to working with the tool sets we use for enterprise architecture and business transformation (EA/BT). The following is a short background.

Obviously the overall objective is to improve an organisation's effectiveness (reduce costs, improve income/outputs, ensure regulatory compliance, build asset value etc.). This requires managed change. I had focused how to improve the quality of transitions from RHE's inception (the best people, methods and tooling). We had tried using a wide range of OTS tools (e.g. CASE, Ontology, Document management and of course Office suites) and building tools to allow us to manage this information. After many years of trying to determine how EA/BT work could be done (in a way produce sustainable value for clients) and a long term focus on methods (including frameworks) we determined the tooling was inadequate (and the tool limitations fundamentally affected the method).

In 2002 we reassessed what tools were available that could be used to support:

business strategies: drivers, plans, markets, products/services, locations, organisations, resources, change/transitions, projects/initiatives;
business operations: communciations, services, processes, rules, information, organisation etc;
technology architecture: enterprise, solutions, components/systems, etc. Supporting any: styles, topology pattern, interaction models etc. And integrating detailed design models (e.g. UML, ER, BMPL/N, SOA) etc. and integrate data from other sources (e.g. CMDBs);
business and technology alignment: relationships and dependencies between the business and technology;
requirements (business/systems): at various levels of detail supporting an understanding of acceptance/contracts/terms and design/delivery;
change over time: time based views of all of the above (as-is, to-be, transitional);
change initiatives: programmes, projects (e.g. costs, risks, resources, timeframes) and business cases (e.g. benefits, fit to current environment etc.);

I wanted to ensure that knowledge in all areas (usually oriented at different audiences, for different purposes, but ripe with opportunities for reuse) could be inter-related i.e. so that information doesn't just reside in isolated silos (e.g. a plethora of office documents, or isolated models). I also wanted a focus on models that record explicitly the essential semantics (rather than just how pretty the pictures, are or how elegant the wording is, as often happens in free form documents and diagrams). This knowledge hub, with various interchange information mechanisms, would:

manage the semantics: model any object, and relate it to any other object; for a predefined library of object we would have a predefined set of properties, methods and relationships to other objects; it would be easy to change the modelling language (objects, relationships, properties, methods, appearance, nesting etc.); and we would be able to structure the knowledge to support any framework (taxonomy e.g. Zachman, FEAR, TOGAF, eTOM, etc.) so these could be tailored to specific customers/project needs etc.)
communicate: create visulations based on any sets of objects with the appearance, level of detail, layout, type information displayed, etc. changed to suit the audience/purpose; allow all authorised people to see the subset of the information they are interested in and annotate/revision-mark that information; allow publishing in any format e.g. office documents, images etc. and via customisable web interfaces (e.g. to support mashups etc.)
integrate: with other sources so we could exchange data with modelling tools; databases/applications; systems tools (e.g. CMDBs); portfolio management tools; programme management tools; dedicated modellers (e.g. project plan, UML, BPM, Data/ER, SW architecture analysis tools); etc.
easy to use and automatable: allow users to very quickly and efficient create models with very little knowledge of the tool (and very little training), to support workflows associated with maintenance and use of the knowledge.
open and extensible: to be standards compliant and implementation technology and technical architecture agnostic. To be able extensible so it can be customised to exactly what we or a client believes is needed.

Eventually (in 2003) we found tooling that provided a client visual modelling capability and a simple server side repository. During the initial implementations it became apparent that to be successful a combination of visual modelling, forms (web forms/dashboards) would be required to make implementations effective for large organisations (and to overcome organisational impedance). It was also recognised that essentially what the solutions represented was effectively a data warehouse /BI solution for the CIO (and IT) and that typically this was the one area of the enterprise that was not served well by IT. So in addition to the above what was needed was:

powerful analysis and reporting: to be able produce reports (using standard reporting tools) in whatever form (visual, textual, dashboards) and type (Word, PDF, web forms etc) is required and access these reports from portals and client tools so the knowledge can be visible to all stakeholders in a way to suits there specific needs, roles at each point of interaction.
tool to ensure the quality and currency of information: so we could automate the collection of data (where there is another source of record e.g. ERP, CMDB, etc.), to maintain policies on data (that allow data quality to be monitored/assessed), to allow easily ad-hoc updates by many users (who can do so as part of their day to day job) and proactively survey/poll users (when it is believed the data is out of date).
secure, scaleable and accessible: to support a large number of ad-hoc users (many that will only interact with the systems for a small % of the time but all of whom have an interest or are guardians of bits of the jigsaw puzzle.
tailored to specific purposes: solutions (based on tailored metamodels, user interfaces, system interfaces) to support specific jobs e.g. enterprise strategy or architecture; business cases and investment plans; technical architecture e.g. solution/integration/service/data/storage; or managing requirements, metadata, design, acceptance, programmes of work, security, business continuity
sophisticated management of multiple states: as in reality large complex enterprises have many initiatives operating each of which is expected to change the current state (at different points in time) and automate the way the changes will ripple through those states.

So in summary our current requirements could be summarised as:

suited to business (and technology) orientation - so ideally one could start with the business side e.g. able to manage business drivers and requirements and solutions.
flexible, extensible and customisable (language of modelling, user interfaces, data interfaces, datamarts, analysis and reporting) - so modelling can be done in terms/language suited to the business
powerful visual analysis and representations (for large amounts of data, power users, and design)
supporting a broad and diverse community of users
automated data collection
multiple states and transitions between states

Having resolved the tooling issues – we then focused back methods – because it was clear that many initiatives in this area failed because people did not have a well developed implementation methodology. See (EA implementation)

Contemporary technology platform design

2008-04-22T12:24:00.003+10:00

(shameless plagiarised from this work on SOA - real time enterprise)

IT Platform strategy needs to be driven by an organization’s business priorities. It is these priorities that set the drivers from which an application, system and network infrastructure strategy can be created. The increasing importance of IT as the digital value chain of the business, positions IT executives and their organizations to be more strategic and critical than ever before. IT organizations must transform from a “lights-on” culture to a “strategic differentiation through IT” culture.

An IT platform should:

combine decision support and just in time fulfillment with real time execution & information availability
deliver services when needed- as needed based on the explicit service requirements of the business.
afford organizations the ability to implement, new, unique products or differentiated capabilities in a timely manner for purposes of competitive advantage & operational control
leverage and reuse common component services (both business & infrastructure) for productivity, efficiency and competitive advantage purposes.
provide the necessary “plumbing” – rich user experience, dynamic execution environment, intelligent mediation platforms, real time data frameworks, optimal system footprints, dynamic network coordination, automated orchestration and tooling to enable autonomic management, monitoring & reporting

Some common questions driving a move to new platform are how to:

become more flexible and responsive to the dynamic needs of the business
simplify & reduce the complexity of the IT environment
get more value out of project & operational IT spend – both systems & people
reduce costs while delivering improved service
eliminate dedicated silos of data, systems and infrastructure as they exist today
reduce the time it takes to build and deploy new business services
implement and sustain predictable qualities of service

A platform has to produce services that respond to the business in four key areas:

business services – (information, automated logic, intelligent analysis)
infrastructure services – (federated query, caching, execution, messaging)
infrastructure resources – (storage, network, compute)
systems performance management – (service execution that alleviates/minimize any compute, memory, I/O or bandwidth limitations and meets service levels)

This helps address datacenter management challenges of:

Data Center optimisation: space, power, cooling
Network bandwidth optimisation and management
Enterprise systems management
Dynamic infrastructure management (operational processes and technical skills)

Consequently the key attributes sought in the design of IT platform are:

Service orientation

components and services are loosely coupled
components and services are not locked to an implementation technology
business logic and data is not be hard-wired to data stores or a technology/vendor

Real time infrastructure – a virtual, dynamic runtime environment

service requests are via: message framework (publish and subscribe), grid service (scheduled, on-demand, adhoc), fabric service (application server container originated)
services are dynamically allocated based on: service contract requirements of speed, throughput, load, calendar, wall clock, costs/margin rules etc.
performance management (applications, network) and dynamic load-balancing and message brokering
consumption and usage monitoring, logging (task, resource, user, transaction, job, etc.) and reporting (usage, service level compliance, trends, service allocation, efficiency, etc.)
policy driven infrastructure provisioning & configuration management
real time transaction workload management, transactional data caching and synchronization.
meta-data repository and data transformation services, meta-rule repository with real rule evaluation.

Service oriented infrastructure utility – policy driven consumption and fulfillment

ITIL/ITOM best practices
Proactive capacity planning
Multiple service fulfillment strategies
Dynamic network routing

Service oriented product management – repeatable discipline that defines the products, services, policies and infrastructure for service oriented business.

explicit management of the alignment of the business (strategies and operations) and IT - Service management that is suited to the granularity of services provided and consumed (service level management, service life cycles, service catalogues)
systems integration architecture and team
utility infrastructure model oriented at end to end optimization
asset management (for reuse).

Communicating the big ideas to a broad community of people.

2008-03-26T09:32:00.002+11:00

The value of large format diagrams on walls is underestimated as a way of communicating essential concepts to a large community of people.

For a millenia (e.g. frescos, murals etc.) have been used to communicate common concepts to communities where the individuals didn't have the ability (let alone the time) to read the texts that provided the details.

It could argued that icongraphy proved an effective way of ensuring the main christian churches remained united (with people all seeing the same big picture), and that the divisions arose when people started reading the texts (and focusing on details of interpretation).

The essential elememts of many complex designs (of all kinds) can often best be described diagramatically e.g. buildings (plans, elevations, sections, perspectives), cars, electrical schematics etc.

It is surprising that this method of communicating the design of businesses and IT systems is often under valued.

IT must be the only complex design discipline in world that tries to communicate complex plans, designs, roadmaps etc. in a A4/Letter sized pages. In some absurd homage to Word (or similar document formats). Or in the futile attempt to pretend that these kinds documents are suited to communicating complex models, plans and designs (when their real strength is narrative i.e. they are good at telling stories)

The problem in this context i.e. complex design and planning is that there is an almost infinite number of possible stories (for different audiences, different perspectives etc.) and the underlying parameters change (albeit incrementally) - so any narrative ends up be at best partial and usually misleadingly or inaccurate.

Analysis and modelling

2008-03-14T07:37:00.004+11:00

Analysis modelling

Basically modelling consists of doing the analysis - and recording the results in a modelling tool of some kind, whereas analysis consists of doing the analysis and recording the results on paper or narrative document/presentation of some kind. If the analysis is done soundly it represents 90%+ of the effort or modelling, and modelling ensures that the analysis is done corrected, is recorded, and can be examined and updated.

Why then do people have the impression that doing analysis on paper is far faster than modelling? It is because they do half baked job of analysis and the method of presenting the analysis (narrative document/presentation) allows this. Often in fact it encourages partial analysis because the "analyst" has formed conclusions (based on prejudice e.g. what worked last time, what would suit them) and good analysis could undermine these conclusions.

There are a number of ways of doing and presenting analysis (e.g. business analysis, technology issues analysis etc.). Often analysis is done in the head and results presented using unstructured data e.g. Office documents (Word, Powerpoint etc.). When this is done there are a number of problems - the exact relationship between data and the conclusions is often not recorded explicitly and in detail; and this almost inevitably leads to short being taken (which exposes the a major weakness of analysis done in this way). This is find for the analysts (as the data/relationship - to the extent they are known - exist in their heads), it is not OK for the person for whom the analysis is done.

Analysis consists
- determining the metamodel and semantics (based on the what is being analysed)
- gathering the items data
- relating the items data
- recording the data/relationships
- reporting on the conclusions (based on an analysis of the data and how it is related)
- presenting the conclusions and usually the basis of them (data/relationships)

The data/relationships includes (facts, beliefs etc. and goals, preferences) and the conclusions are usually in the form of recommendations.

Modelling basically consists of exactly the same steps - but the principle difference is a modelling tool enforces the semantics (which goes a long way to validating the data/relationships) and makes it obvious when data/relationships are incomplete and or inconsistent.

This means that in practice often gathering and relating the data with rigour (i.e. so that it is accurate, explicit, weighted etc.) is more difficult than is anticipated. This is not an issue with modelling - it is an issue with doing analysis properly.

See also:
- Why paper based approaches don't work
- Why EA can't be done on paper

TRMs and change

2008-02-25T13:32:00.001+11:00

Categorisation systems

As with any system of categorisation when the data to be categorised is known and/or static it is easier to develop a useful system of categorisation, and the systems of categorisation seldom needs to be changed. When the data to categorised is unknown of changing quickly it may be necessary to change the categoisation system i.e. based on changes in the nature of the data.

Technical Reference models (TRM) are often used to categorise an enterprises technologies or the of types of technologies that could be used by an enterprise (often along with product catalogues, which indicate which specific vendors products are being employed).

TRMs for Technology Visioning

TRMs are put to a number of uses one of which is technology visioning (where the TRM provides categories for fact, beliefs, implications, standards, patterns etc.). TRMs are also used for investment planning (when the things categorised are assets, products etc.).

When looking ay technology visioning i.e. looking at technology trends and directions based on new and emerging technology products and announcement almost by definition the data to be categorised is changing quickly and/or unknown. So in this area it is likely that a TRM will need to evolve.

In areas where technology is fairly static the TRM will probably be fairly useful (correct, accurate, well balanced) because the technology is fairly static it will not be the focusing of technology visioning i.e. trends, directions and changes.

In areas where the technology is changing quickly the TRM will often need to be reviewed as technology and business paradigms change i.e. new categories may be needed (e.g. with old categories splitting or merging).

To make this feasible one needs a way of changing the TRM but keeping the associations of elements (facts, technologies, assets, products) to the TRM.

5 things SOA vendors are missing, and 5 things customers need

2008-02-13T11:33:00.000+11:00

(prompted by 5 things SOA Vendors are missing)

This item is refreshing direct and points out that SOA is an architecture (a complex distributed architecture, leveraging many of the traditional EA concepts) and or a meta an architectural pattern. What is needed are products that are elements in an SOA, not products that in and of themselves aim "to be" the SOA. It says to Vendors:
1. Make sure your product works.
2. Make sure you know what SOA is - most who sell SOA technology don't understand the first thing about SOA and typically play "buzzword bingo" reciting terms e.g. agility, reuse
3. Get wise about the approach to SOA - how should each customer approach SOA.
4. Don't sell yourself as "one stop SOA shopping." - in reality, nobody is a one-stop SOA shop.
5. Consider the future - Architectures are journeys, not projects. You need to think long term when you work with a customer and a customer's architecture inserting yourself at key points in the process

What Customer need is people who:
1. Know how to make the product works. Or at least can confirm they don't work, or they are not working as they are meant to. This usually comes from someone who has worked with a number of products of each class.
2. Know what SOA is - often these will be people whose goal is not to sell a particular technology and rather focus on what the business aims to achieve.
3. Are wise about the approach to SOA - and know how to engage with customers at many different stages (before they need a product set, when they do need and are selecting a product set, when they have a product set).
4. Know "one stop SOA shopping." - doesn't make sense, and at it worst ends up in the customer being captured by the vendor (which is most vendors' goal)
5. Can consider the future - will be around for the journey, and are able to think long term when looking at a customer's and a customer's architecture.

It is staggering to think that Customer's would look to the major product vendors and outsourcers for independent advice in this area.

Linking SW Architectures with Enterprise Architectures

2007-12-13T07:49:00.000+11:00

(prompted by an interface between Lattix and Troux)

In an Enterprise Architecture (e.g. Troux) an organisation would record its applications (hundreds to thousands). The level of detail they would record about applications would vary. Often not much detail is available (i.e. to hand) regarding the internal aspects of the applications (i.e. its internal modules/components and how these inter-relate).

Application portfolio optimisation work is typically focus on rationalising the set of applications at a macro level (e.g. often duplication of function arises as a result of mergers).

A next level of analysis would involve looking at the modules (or components that application is constructed from). This may present opportunities for more atomic refactoring of the application portfolio and will insights into candidates for service representation.

When an application is analysed using Lattix (SW architecture analysis) - we can use the information provided by Lattix (based on an examination of the actual code) to augment the information in the Enterprise Architecture (i.e. add the modules).

See also Enhancing EA

Model driven SOA

2007-11-29T11:16:00.000+11:00

(prompt by Model Driven SOA emerges)

The following points are made in this item (that we have been saying for a number of years):

If you want to address SOA in a scaleable way, you can't do it without support for modeling.
Many people underestimated how fast BP modeling would become a topical issue for organizations.
Historically, we only had UML process modeling that was low level and wasn't much use in SOA. Developers pretty much stuck with gathering requirements, which usually ended up gathering dust on a shelf, and then got down to coding applications.
With the adoption of SOA and BPM (BPMN, BPEL etc.) that approach is going over the application development waterfall in a barrel.
The idea of a BPMN specification linked to BPEL that allows automated code generation is intriguing, especially when you combine that with business rules capabilities.
if you really want to get to reuse, you really want to have a higher level model-based oversight on what the different components are and how they interact.

It will of course be interesting to see how Telelogic's products prosper in UML oriented IBM unit (Rational).

Modelling Business Strategy

2007-11-08T13:48:00.000+11:00

We have had a number of conversations with business people and consultants about the merits of modelling approaches for driving strategic alignment in organisations.

Whilst there are many techniques for defining strategy and flowing it down through the organisation (e.g. Balanced Scorecard), the processes for managing the relationships between these organisational goals and initiatives are typically quite "loose".

Modelling these relationships in Troux Metaverse facilitates a mechanism for maintaining the ongoing integrity of such processes, as well as being able to use the tool to actively manage transformation initiatives and IT spend.

I have written a short document on this which can be downloaded here.

Guy

Managing complexity in business and IT strategy and architecture

2007-11-08T10:45:00.000+11:00

(the need to manage complexity better in business and IT strategy and architecture)

A working group from The Royal Academy of Engineering and The British Computer Society - looking "The Challenges of Complex IT Projects" (ISBN 1-903496-15-2) - noted [comments in square brackets are mine]:

Complexity is increasing: the challenges associated with complex projects is increasing rapidly. These are fuelled in large part by the exponential growth in the capability of hardware and communications technology, and the corresponding inflation in people’s expectations and ambition

Unprofessional practice is common: A striking proportion of project difficulties stem from people (customers and suppliers) 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 people at all levels. [e.g. about what class of tools to use for managing complexity]

IT doesn't learn well from more mature professions: There is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management procedures e..g risk management is poorly understood, systems architecture is not appreciated.

Managing complexity requires new methods, processes and tools: problems relate to the people and processes but further in developments in methods and tools is required to support the design and delivery (in particular regarding effective management of complexity)

[See how other industries organise things: by analogy, by example ).

Ehancing EA with SOA

2007-10-30T15:35:00.000+11:00

(prompted by Enhancing the EA with SOA - by CBDIforum)

SUMMARY

Enterprise architecture is a slowly maturing practice used in an increasing number of organisations, as a valuable tool, not just from a technology perspective but also in terms of understanding how the business operates and what determines its operations (regulations, strategies, market factors etc.). Service Oriented Architecture (SOA) is being put forward as an approach for organizing systems and technology infrastructure architectures to better enable business agility. It is going to be critical that best practice in EA is extended to incorporate SOA perspectives.

This is precisely the area RHE has targeted through a focus on both EA (tools and methods) and on SOA (enabling technologies and methods).

DETAILS

For large organisations architectural complexity has become so great that the adoption of new technologies is a costly, high-risk, and time-consuming endeavor with legacy solutions often lingering for years after newer technologies are adopted. For many organizations agility enables new technologies to be exploited to create a competitive advantage in the market place. EA techniques are widely used to address this complexity, and to facilitate better decision making.

SOA is seen as one of the key enablers of business agility and its widespread adoption throughout the IT product vendor space necessitates that organizations learn to manage and exploit SOA. Everyone from new internet oriented organisationss (e.g. Google and a pethlora of other SaaS vendors) to the old legacy ERP vendors (e.g. SAP, Oracle) have adopted SOA as the primary paradigm for systems integration. Business organizations will rely more heavily on sets of third part products and services integrated to create their unique solution set (rather than large bespoke applications).

To capitalize on new technologies and products, organizations will need to mature their SOA capability so they can effectively integrate these packaged services to transparently support their business operations. This means incorporating SOA into their EA planning process.

There is also a more urgent driver for incorporating service architecture into the enterprise architecture. All of the main development environments today can rapidly publish .Net or Java classes as a Web service. The implication of this is that your organizations service architecture may be defined at the whim of any developer or software designer. And while a few may be professionals making good design decisions, very few, if any, have the enterprise perspective to identify the optimal collection of services for the enterprise without a broad planning process.

The EA must provide the target service portfolio plan that enables all these developers and architects to concurrently and semi-autonomously drive the software for which they are responsible toward a common strategic vision.

For many organizations, EA provides the first enterprise view of the systems architecture and the results are often enlightening. System redundancies and over-extensions become readily visible as do some cross-departmental value chain inefficiencies. As EA exposes these opportunities for improvement, organizations begin to analyze how to capitalize on them. This is where SOA comes into play.
Inevitably, the solution to these problems requires the containment and elimination of some technology solutions, while others are being extended to support a broader scope of use within the organization. SOA provides the means (formal techniques, best practices, and work products) that enable these problems to be solved and communicated with new clarity of purpose.

Software architecture tools also play a role here in allowing views of the major modules of applications and interactions between these modules to be understood. The modules and interactions may useful insights into redunancies across the applications portfolio and possible integration points which may be candidates for externalised services.

The transition process RHE has long recommended is to contain, through encapsulation (via introduction of a technology capability service), a technology targeted for retirement. This allows the business requirements to be aggregated on this service and facilitates the selection and downstream adoption of a newer technology. Once all dependencies on the older technology have been moved to the newer one, the older technology can be retired. Such a transition approach is inherently service oriented.

The CBDI item goes on to describe Zachman's framework and suggests most EA activities focus on the top three rows (where as I see very little if any focus on the top two rows - and most of the focus has historically been on existing infrastructures, applications and technologies standards (i.e. as far away from the business as possible). It then goes on to say that "these architectures are all similar from the perspective that they specify particular views" - which is clearly not really the case - as Roger Sessions has pointed they are actually not even of the same class i.e. TOGAF does not define a taxonomy, Zachman does (but the exact views and not that clear), FEAF defines meta-views (but is imprecise on what specific views might be), and it focuses on Reference Models (which are useful categories for investment planning and business cases), and only DODAF really focuses on views.

Most glaring they fail to define a key failing from the Zachman taxonomy defined 20 years ago i.e. that it doesn't really define interfaces (user or system) very well - because in what was essentially the "single mainframe, single application, terminal based access for an internal audience" model of 1987 these things didn't warrant much sufficient attention.

Table 2 suggests "Traditional EA Model Elements" include: Business Rule, Event - yet few EA's I have even seen have good organisation wide inventories of either. Good EA (if they were of the business) would also surely have a business's products/services, markets, projects/initiatives, locations etc.

The rest of the item is quite good in describing a services and how they should be modelled to allow them to be instantiated, used and operated.

EA for SOA (CBDIForum)

2007-10-26T09:29:00.000+10:00

(prompted by EA for SOA?)

This raises some issues - but doesn't answers for a number of them.

1. Current Architecture Death March - Automated collections [ETL] from the plethora of silos makes these significantly easier, as does role based Web portals to the information i.e. that allow the changes to be recored as part of day to day business.
2. Technical Reference Model (TRM) Stagnation – The biggest issue with TRMs is that different taxonomoies are suited for different purposes e.g. Asset management (which tends to be around products that can be bought), Standards management (which is oriented around more abstract concepts - i.e. not around products), Organisational divisions of responsibility (i.e. that organise technologies in large organisations around the organisations that will support them e.g. you will find all OSes looked after by what is really Server oriented systems group) Technology architecture (which lies between Asset and Standards). There are several solutions - one is use different TRMs for different purposes (modern EA repositories allow things to be classified using many taxonoies)

3. EA Compliance Becomes a Barrier - The difficulty in measuring the value of EA is
well known (e.g. I think it relates to counterfactual reasoning - see http://ea-in-anz.blogspot.com/2007/08/justifying-architecture-and-strategy.html).
Town planning is a good parallel. Town planning compliance is a barrier to laissez-faire property develop - as it should be. One can also see there is nothing wrong with a "critical business initiative" overridding the "planning authority's" existing plans - provided it is done openly, for well discussed reasons and by exception. Major programme of capital works involve overriding existing town planning regulations, and local planning guidelines on a regular basis.

4. Why so much effort was being put into hoovering up information about existing systems - because you are starting at wrong place i.e. the systems (which are a technology legacy that reflects a combindation of what the business wanted to do once, and how it once considered best to implement this). The right place to start is at the top (in the business) or as near the top as possible. Process models are also too detailed a place to start (this Webinar discusses some of the issues -http://www.troux.com/company/events/webinars/20060511caston/)

SOA and EA - issues with EA can apply to SOA. The difference is that the failure of SOA will be more obvious and damaging to the business (you can't bury you SOA mistakes as easily as you can your EA mistakes). see: http://ea-in-anz.blogspot.com/2007/08/soa-must-be-underpinned-by-better.html

A canonical data model - You can't like processes to them because in practice they seldom exist (I have never seen one that is anywhere near complete). See http://ea-in-anz.blogspot.com/2007/09/enterprise-data-management.html

I agree that SOA is a core enterprise level strategy. But the SPP needs to be built from the top down (using Zachman as a reference for top and bottom).

SW Architecture feeding into Enterprise Archiecture

2007-10-23T11:37:00.000+10:00

(prompted by work with Lattix)

SW Architecture analysis compliments Enterprise Architecture
Lattix is an excellent fit with other offerings e.g. those targeted at software design and development, and those oriented at the business architecture and strategy and its relationship to systems. Lattix should assist people reduce the costs of maintaining and extending their systems, whilst also improving the agility and reducing the fragility of these systems.

SW Architecture analysis compliments OO design modelling
RHE was a very earlier adopter of OO analysis and design techniques and introduced UML to many clients in the mid 1990s so I think we have fairly good to top to bottom view of this domain. While UML is very useful in analysing the exact characteristics and behaviour of a relatively small number of critical objects (to be constructed) it is fairly clear that UML does not provide a good way of managing large SW architectures (ie. set of objects have have been constructed and/or elements that do not involve engineering objects).

SW Architecture analysis and EA touch points
There is quite a natural point of interface between an EA systems and SW architecture analysis tools. A EA knowledge base brings together information held in many different discrete silos e.g. business goals, strategies, plans, initiatives etc. (often held in Office docs); business services, processes, rules, information, etc. (often held in discrete models and/or Office docs); extant systems (technology platforms, applications, datastores etc. - held in a range of places e.g. CMDBs); programmes and projects; etc.

Assuming an application is held in an EA repository - and it has also been analyzed by a SW architecture tool - it should be possible to augment the EA's knowledge of the application with information about its structure (e.g. modules) that is known and accessible from the SW architecture tool. This level of detail may be useful when changes or adaptations are being considered. It would also give EA's a more detailed understanding of the applications portfolio - which may provide more insight into the duplication of functionality across the portfolio of applications (supporting rationalisation, refactoring of the set etc.), common services interaction points (for SOAs) etc.

OTS applications
Obviously if one looks at an application portfolio in a large organisation many of the applications are OTS or constructed by third parties (and no insight into their internal structure is often provided). Though no doubt if the organisation developed a habit of recording the major modules within applications it may be that progressive vendors could provide the level of information necessary.

Zachman as a reference point

Using Zachman as a context - Lattix sees its positioning as at designer/logical and physical/builder levels. I also see Lattix operating at the Detailed representations/Out of context/sub-contractor level (i.e. completely outside the bounds of EA per se). In the following diagram I don't see the connection to services at the conceptual level correct (I think it is an attempt to overcome limitations in Zachman's suitability for SOA).

How lattix represents logical and implementation information
Having established a relatively positioning for the information Lattix collects and analyses we can examine how this information is represented.

Business and IT transformation

2007-10-15T08:05:00.000+10:00

(prompted by New Tools Give Enterprise Architects Multi-Tiered View)

Short version of this is: The trouble with strategic transformation in the enterprise, and managing the IT projects that support that transformation, is modeling all the moving parts of a complex enterprisey e.g. how will a new data center affect the company's bottom line?

It is easy to represent the as is and the to be, but transformation, scenarios, assumptions, are more abstract and with big changes one wants to minimise the risks.

EA repositories allow organisations to record/understand how the different aspects of a enterprise fit together today, and how they may fit together in the future, but they struggle to model complex change sceanrios that can show exactly how to reach future states (through different paths) and what the enterprise will look like at any interim point in time.

Troux Initiatives provides multi-state views of an organization (today, when a transformation is complete, and the various paths that can be taken to achieve a goal). All of the information from all the plans for transformation (and the aspects of the enterprise affected) are stored in a repository that actively tracks the states. Scenarios allows you to link a things a repository and say they're associated somehow.

See also:
T7 announcement
CIO is key to business and IT transformation

Improving IT's reputation and alignment

2007-10-03T08:23:00.000+10:00

(prompted by IT's bad reputation and IT projects not focus on delivering business value)

The 1st of these points out that many IT organisations are seen as part of the problem instead of part of the solution (and some expertts on management strategy suggest "When you want to run a quick experiment, I tell people don't go through the IT division because they are just going to tell you 'no,' and it's going to take forever to get it done."). It notes

some IT managers come across like the stereotypical bureaucrats, shuffling paper (and paper is a big part of the problem) [see problems with paper]
that the inconvenient truth for some is that they must change their ways of managing if they want to be leaders. CIOs must create an environment where the empowered worker can thrive and educate their colleagues on how technologies are disrupting the way companies operate. [see CIO's challenge]

The second suggest half of companies measure the success of IT projects based on whether they deliver to budget, rather than the business value achieved by projects (i.e. rather than how projects can deliver measurable value and be mapped on key business goals). The use by CIOs of spreadsheets to plan projects is seen to to give them a lack of visibility and control, and makes it difficult to link aspects of the work. They should focus on tools that give them a view of how projects align with their business, their technologies and to each other.

Why don't most IT processes work well

2007-09-27T10:43:00.000+10:00

(prompted by the common failure of processes for fairly obvious reasons)

The key problem with most IT processes is that they don't deal with the complexity very. And IT is full of complexity (and is getting increasingly complex)l. The irony is that the IT technology used to implement most IT projects is perhaps 20 years or more old i.e. Word documents, Spreadsheets, Diagrams - but IT people unable to see that they more than most other aspects of the business are failing to execute effectively because they have not kept up with technology

I will give some examples:

Development methods (e.g. RUP) - putting aside the fact that the method is to a large extent based on the false premise that the functional business requirements can be captured in UML. A key impediment to its success is that its implementation involves a number of documents. These documents are necessary to contain knowledge about the project. They contain information that is high inter-related, and needs to be explicitly connected, and should be able to be analysed. This is manifestly not the case when RUP is usually applied. What is really required is a model/knowledge base that represents the project that can produce the RUP artefacts as reports (and there be more of these tailored to specific audiences and aspects of the project than are produced at present) - while at same time allowing the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.). This solution would also allow management dashboards to exist to allow management at atomic level.

Of course RUP really came from the package SW development domain (which is also where most C++ programming was done). In this context i.e. where there is no specific business as such, no specific business users etc. and where the task is very much engineering (vs the capture and elaboration of requirements that emerge from mist - as is the case with most bespoke development) - UML is quite well suited.

Business continuity - is another example of something that is usually implemented in a plethora of highly connected documents. These documents must contain knowledge about the business, technologies, plans, compliance issues etc. and these aspects should be explicitly connected, and able to be analysed. What is required is a model/knowledge base that represents the business situation (including plans for ensuring continuity of operations, and alternatives for executing) that can produce the documentary artefacts as reports and allows the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.)

IT Investment management - [..WIP]

Troux 7 Released in the USA/Europe

2007-09-25T07:49:00.000+10:00

Troux Delivers Industry’s First Enterprise Platform to Support IT Transformation

Troux, the leading provider of software solutions enabling successful business and IT transformations, announces the industry’s first enterprise transformation platform, Troux 7. The new, comprehensive solution, based on Troux's EA technology, addresses the primary objectives of CIOs and executive leaders i.e. to deliberately and systematically reduce costs, manage risks and drive investments.

Business transformations (e.g. global expansion, mergers, the creation of new product lines) can't be implemented without a set of IT activities to support the change. Often executives fail to understand and IT fails to communicate how such activity will impact the business, resulting in lengthy, complex projects and excessive costs.

A recent survey sponsored by Architecture and Governance Magazine revealed that 20% of respondents continue to struggle with demonstrating the value of IT projects to the executive team, leading to early termination of the project or even perceived failure.

"Alignment of IT to the business continues to be the most critical challenge for CIOs. We’re seeing ongoing frustration from the business as IT struggles to be more agile and proactive in their support of business requirements. A key barrier to this is lack of visibility to the range of IT assets, the relationship among the assets and their relationship to the business,” said David Hood, CEO of Troux. “With Troux 7, we’ve created the only system with the complete set of capabilities for EA teams and IT departments to successfully automate the understanding of the enterprise and how IT relates to the business. Troux 7 delivers a rich analytics platform to create transformation initiatives, allowing gap and impact analysis in multiple scenarios to identify IT support requirements for the business. Coupled with a baseline transformation plan for business alignment and the mechanism to monitor execution over time to ensure effective support, once again Troux’s innovation delivers an unrivaled solution to the market."

Troux is represented in Australia and New Zealand by RHE. Troux 7 is expected to be released in Australia and New Zealand next month.

To see the Troux press release click here. See also:

Troux adds advanced BI to platform (IT Week)
Troux makes enterprise architecture transformational (Computer Business Review)

Data Governance - Maturity Model

2007-09-21T10:31:00.000+10:00

(synopsis of: 7 Stages for Effective Data Governance by Martha Dember)

There is a tendency in organizations to be complacent about data quality and integrity issues (which could compromise credibility of the organization's information).

Data Governance:

is the development and integration of a set of rules/policies, guidelines, and standards - for managing data (not just a collection of ad-hoc data quality projects)
provides the framework for IT and business to worktogether to establish confidence and credibility in the enterprise's information.
is implemented by a data governance management team, of IT and business associates, unified by a common goal i.e. to ensure: data is what it is supposed to be (Data Quality); data is in the correct context (Data Integrity); data and its associated metadata are accessible (Data Usability)
ensures the authority to manage data is properly delegated from the senior-most levels, and that parties are held accountable for executing governance policies as required by their respective mandates.
has policies and procedures that balance effective information access with appropriate use of the information.
is a programme (i.e. is not an application, that can be purchased, installed, and implemented with a specified end date) but a process that, over time, affects the culture and the way an organization conducts business.

Data Governance Maturity Model - requires a plan or framework (along with other things). In a data governance maturity model one can define seven stages of maturity .

1. Strategy and Framework
The Strategy identifies data issues, their causes and effects, and methods to solve the issues.
The Framework defines the roles/responsibilities of the data governance team and the relationships and dependencies between the data governance team and the data architecture.

2. Scenarios and Validation
Tests the data governance strategy and framework e.g. takes a data issue (reactively) and determines the cause/effect of the issue, and propose a solution to: refine the processes/framework; determine the communications (how best to implement the steps, and who should play roles).
Benefits: PoC using industry best practices that can be adapted to the organisation

Stage 3: Formalized Organization and Responsive Process Rollout
Formally define the roles (e.g. job descriptons)
Benefits: Accountability for establishing and maintaining data quality.

Stage 4: Proactive Process Rollout
Identify business events or activities that causes problems (data issues)
Benefits: Proactive processes improvements, better communication between business and IT (people can collaboratively manage data)

Stage 5: Expanded Business Involvement
Explicit buy-in from key stakeholders and executive management in the data governance program. Standards compliance monitoring is incorporated as a part of performance measurement; and data-specific technology, processes, and organizational components are aligned with the company's most important business objectives.
Benefits: Continuous improvement efforts are measured and monitored (metrics);Associated processes (e.g. SDLCs) can be improved; Data governance efficiency is improved (the knowledge base is used to reduce future project effort/duration)

Stage 6: Stewardship Culture
Governance across the Enterprise reconciles priorities, expedites conflict resolution, and builds cooperation in support of data quality as a common objective. Data quality education and awareness programs are an integral part of the on-going employee training programs.
Benefits: There is a common focus and delivery and everyone acts as a data steward (extending to business partners/channels)

Stage 7: Strategic Governance
Data governance and compliance becomes real-time, change-driven, on-demand process that continually assess risks, update policies, and manage resources across the enterprise. People, processes, and technology working together organically and autonomically that result in an effective data governance program.
Benefits: Utility of information can now drive flexibility and agility of the organization and result in a streamlined/efficient organization.

Thinking SOA (are the issues really that new?)

2007-09-20T09:00:00.000+10:00

(prompted by thinking SOA)

I agree with the conclusions i.e.

- SOA is a core aspect of EA (and EAs that get this will get SOA more quickly)
- SOA does have new some challenges especially around lifecycles, service quality management and inter-party agreements - but think that in but in many cases the challenges have always been there - now it is just harder to bury your mistakes.

I disagree with some of the things implied i.e.
- Good EA has always been about interoperability (driven by business goals such as agility) - and never about layers of technology. So this is not something new with SOA.
- "Traditional enterprise architecture" is Technology Architecture (NOT EA). Many of frameworks, methods and tools - have been manifestly unsuited to real EA for a decade (hence the how few really success EA projects there are). So this is not something new with SOA either

See also: EA/SOA a shareholders issue?

EA and SOA shareholder issues?

2007-09-15T08:06:00.000+10:00

(prompted by: Could Lack of SOA Drive Shareholder Lawsuits)

[WIP]
I can't really bring myself to agree with the conclusions in this item - that the absence of good EA's could drive lawsuits.

Key assertions from this:
1. Shareholders are looking at enterprise architecture efficiencies
2. Many major public companies don't have efficient enterprise architectures
3. Stockholers assume that IT/Architects, are doing their best to make the architecture optimal for the business. However, in many cases, that is not true.
4. Years of neglect, lack of talent and understanding, etc. have created dysfunctional EAs.
5. Bad EAs hindering corporations ability to make money and return value to shareholders
6. This could drive lawsuits where bad EAs may need to explained in depositions (during law suits).
7. SOA are not a fix for bad EAs - they will just make bad ones worse.
8. What is needed is a long term cogent SOA strategy and this is complex and hard, but worth it if you do it correctly.
9. Shareholders may ask for complete audit be done on the methods and practices in building an effective EA

Comments re the points above:
2, 3, 4, 5, 7, 8 - I think are fairly well known i.e. - Most major enterprise don't have efficient EAs and years of neglect, lack of talent/understanding are a cause. Few IT orgs are doing their best to fix this. Bad EAs do hinder ability to return value to shareholders and SOAs will make bad EAs worse (adding complexity) and what is needed is a long term cogent strategy. These strategies and architectures are complex and hard to do.

I think 1/6 - are unlikely. That shareholders will look at architectures and focus law suits on the deficiencies seems improbable to me for many reasons.

The last point 9 - may well make sense. They may ask for audits to be done on the methods and practices in building an effective EA But the challenge will be finding auditors with the knowledge and experience to do the auditing who are actually impartial e.g. most of the organisations that are recognised as leadings in EA seem to have unignorable conflicts of interest i.e. they are primarily vendors of systems or software; they generate huge incomes from the implementation ERP systems (often following services associated with "impartial" evaluation of ERP solutions); they don't really understand some of the issues associated with EA.

See also SOA's must be underpinned by better management

Enterprise data management

2007-09-14T11:13:00.000+10:00

(provoked by frustration with solipsists)

In 3 years, the bytes of data generated by cameras, phones, business systems and other devices will equal the number of grains of sand on the world's beaches. While most will be consumers driven more than half is expected to cross corporate networks. Even if one just considers business data - there will be a lot of it e.g. Wal-Mart generates 1TB of transactional data a day.

Data management strategies are going to have to improve to deal with business policies, security and compliance issues. Today the average organisation can't even provide a high level map of what data it deals with i.e. it is buried in silos (often maintained by a technical clergy interested in their particular arcane way of dealing with data e.g. ER modelling, Documents, Multimedia etc.).

You can't manage what you can't see, and even if you can see it, that doesn't necessarily mean you understand it. Few organizations have a real handle on the relationship between business information/data and the underlying ICT systems that implement the data (in its many forms). Worse, if they did have visibility into the data, they would often discover that they: have several different systems handling these data; and an increasingly diverse set of internal and external stakeholders; and complex governance and compliance issues.

The end result of all this confusion is that most CIOs can't really have a candid conversation with their business counterparts about what the real issues are associated with managing todays data or dealing with more data. The typical response is to frantically try and find out where the data is (e.g. in applications SAP, Oracle, bespoke; repositories: file, data, document, content, image etc.) and then try see how hard it is access it, find it, archive it, change it, aggregate it, report on it etc.

Why hold data in an enterprise knowledge base
Some reasons for holding data in an Enterprise knowledge base are to understand:

how the data relates to the different aspects of the enterprise e.g. what data are associated with what: process, service, objects etc. (for impact analysis, completeness checking, benchmarking against reference models etc.);
where and in what form this data has been implemented e.g. in what systems, in what form (e.g. SQL, XML, File, Image, other etc.)
what the business concept is (i.e. information as distinct from an implementation of if) so it is clear how it is affect by external factors (e.g. laws, compliance regulations), internal governance mechanism (e.g. life cycle management), etc.

What is wrong with the current approach
It is clear that this information can't effectively be "managed" in documents or in people's heads (often the failure of this approach becomes apparent within a business/ICT transformation project, and almost always it become apparent across projects, and time). It is clear that dedicated tools associated with various aspects of technology implementation have a role (e.g. ER modellers associated with relational data, XML modellers, ontology modellers, ETL and data mapping tools etc.). Therefore what is required is an understand of how one moves from the Enterprise domain to a technology domain.

What are the impediments
Typically the impediments to maintain an accurate view of the information/data in an organisation are:

practitioners in one of the technology silos (e.g. ER modellers, BI/ETL modellers, XML modellers, UML modellers etc.) who can see need beyond their immediate needs (i.e. to the broader needs of the project and organisation).
projects which focus on the short term or a narrow aspect of the business
vendors who have an interest in developing direct connections to their implementation technologies and thereby locking clients into these technologies.

What would an approach to establishing an enterprise knowledge base include:

Determining the role of the enterprise knowledge base e.g. to act as a central hub tying together all aspects of what is known about an enterprise and the degree to which it will manage our knowledge of data (i.e. the conceptual boundaries between say an enterprise view and an ER view)
Determining the nature of the interface between the Enterprise knowledge base and dedicated implementation oriented tools (e.g. ER modellers, XML modellers etc.)
Inventorying of existing (and planned) data e.g. why it exists, who uses it, where it is implemented (systems, interfaces, store etc.)
Benchmarking based on an industry Reference Models if they exist i.e. in some industries Industry Reference Models exist which can be used (see RHE's documents on Industry Reference models).
Defining architectural principles e.g. what data should be implemented where and how e.g what the source of record should be, what the form of the data should be, what the life cycle issues are (and where these are governed by external compliance regulations).
Analyzing business information for context - what drives it, who owns it, what it relates to e.g. services, processes
Selecting data for optimisation
Developing optimisation programme
Integrating the data optimisation work with other programmes and initiatives
Defining data governance approaches
Implementating the approaches and optimisating the management of the data

[I have just used the word "data" - and have not attempted to distinguish between "data" and "information"; or "information" and "knowledge". This is not to say that I don't see that distinctions can be drawn e.g. Chambers gives the following definitions: data is - "facts given (quantities, values, names, etc) from which other information may be inferred"; information is - "intelligence given; knowledge; ...data"; knowledge is - "that which is known; information, instruction; enlightenment, learning". So from this it seems that" information can equate to knowledge or data; data provides the basis for information (which in turn contributes to knowledge); and that information and data can be stored in a system, whereas knowledge implies consciousness (e.g. people).

CIO key to business and IT transformation

2007-09-11T09:40:00.000+10:00

(provoked by : The CIO revolution in the public sector)

If CIOs accepting this challenge will need to consider what solution(s) they need to allow them to function effectively:

Alignment - of business and IT (how they record, and communicate, manage this)
Visioning - forward-thinking about how ICT can enable/support achievement of the mission (technology beliefs, scenarios, initiatives etc.) and being clear exactly what roles IT plays.
Transformations - support the nitty-gritty of this (programme definition, impact analysis, risk analysis etc.)
Business change programmes - where IT is embedded in approval and management of all business change programmes and investment decisions are clearly seen as the responsibility of the business (how they quickly provide an accurate analysis)
Value assessment - where proposals explicitly identify the business benefits expected and the investment required (including all: business process change, facilities, infrastructure, applications, recruitment, training, marketing and change management, etc.).

To do this they will need to work out how what their business intelligence solution needs to be i.e. that can tie together all the knowledge about their business and ICT - and present it: to specific audiences on specific topics of interest.

Some extracts from The CIO revolution in the public sector:

"...the rhetoric of business and IT alignment has to become a reality."
"... importance of the CIO role in both central and local government. ..."
"... the overall government vision for IT and service transformation but also practical developments on the ground in terms of how the IT function ..,fit[s] with the rest of the business."
"... the nitty-gritty of transformation still has to be worked out ..."
"... the capacity to engage in more forward-thinking discussions about how ICT can enable and support the organisation to achieve its broader mission..."
"... A standard process for the approval and management of all business change programmes is thus becoming more common in both central and local government. IT issues are embedded in this process from the beginning and the investment decisions are clearly seen as the responsibility of the business as a whole. ..."
"All proposals explicitly identify the business benefits expected and the investment required, inclusive of all the elements, including business process change, facilities, infrastructure, applications, recruitment, training, marketing and change management"

See also:
CIOs 'last three years
Eight roles the CIO must play - "... three roles the CIO needs to avoid: chief inertia officer, chief impediment officer and chief inefficiency officer..."
The life of a CIO: It's not pretty - "I have been to India so often that I have started to understand cricket."; "At the same time, the divisional IT guys are playing this cute game; they give great lip service to having common platforms and cooperating, but when push comes to shove -- they push and they shove."
Multiple Roles Eyed for CIOs - the CIO creates possibilities - new kinds of processes, new kinds of strategies, even new ways to reduce costs.

Business and IT transformation

SOA and EA - IBM's lessons (my summary)

2007-09-10T11:00:00.000+10:00

(provoked by: IBM's item on EA and SOA)

My summary of the lessons
1. SOA addresses only a subset of EA domains (i.e. services) and can leverage other EA domains (e.g. information architecture, system management, operational architectures, rules/decisions architectures, function/process architectures, control architectures etc.).
2. SOA governance should leverage EA governance. The service model(s) should be developed and maintained by the SOA experts just as other aspects of an EA should be developed and maintained by their experts e.g. data/information, architecture, rules/decisionms, process arch, systems etc. The Services model(s) should be referenced from the EA and architecture review boards should consider services governance.
3. Ideally the funding models for services (and common infrastructures, and functions) should be based on an enterprise level not a project level.
4. SOA infrastructure is an enterprise asset (just like any other infrastructures e.g. information/data, rules/decisions etc.) and should be managed as part of the enterprise system management and comply with enterprise policies e.g. security.

(see also: SOA's need to be underpinned by better management)

EA and analogies with the built environment

2007-09-05T08:48:00.000+10:00

(prompted by erroneous analogies)

EA can be seen to have a parallels with architecture in the built environment. One can examine this analogy from a number of perspectives: functions, roles, frameworks, relationships etc.

Functions

Enterprise Architecture - Town planning
Solution Architecture - Architecture
Iterface (UI/SI) Architecture - Interior design and landscaping
Technical Architecture(s) - Design of: Plumbing, Electrical, HVAC, Structural/Civil engineering, etc.
Integration Architecture - Roading, Reticulation water/power/telecom, waste/sewerage
Security Architecture - Security systems
Developers/systems engineers - Craftsmen, artisans and construction trades - carpenter, brick layer, plumber etc.
Operations - Facilities management and cleaning
etc.

Roles

Community/Town - Enterprise
Property developer - Business owners (focused on their immediate need/benefits)
Enterprise Architect - Town planner (focused on the broader interests over time, across all business owners)
Solution Architect - Architect designs a solution for a business owner
Interface Architecture - Design within constraints defined by the Architect and their detailed designs create new constraints
Technical Architecture(s) - Develop detailed design and inform the Architect of new constraints
Project managers (same role - different focuses) - built environments where the industry is mature and specification clear, focuses on managing plans (costs, time), change and exceptions; ICT focuses on managing scope (which is not well enough defined) and interactions between technologies and disciplines that are immature in themselves (and with respect how they interact with each other (of course they also pretend to manage plans, change, risks etc.)
etc.

Frameworks
Frameworks that allow the different aspects of the solution to be examined (Cf. Zachman) are co-ordinate systems/map projects and measurement systems (that allow relative placements and replacements and spatial relationships to be understood), established division of work by function (lighting plans, electrical plans, floor plans etc.), etc. Frameworks define processes (Cf. TOGAF) are defined within each trade and by the overall pattern of engagement - briefing, sketch design, bulk and location, premit/approval, working drawings, supervision, as-builts etc. Frameworks which define reference models (Cf. TRMs) are defined in many codes and standards and common reference works e.g. Metric handbook (AJ Metric handbook).

Relationships
These analogies also explain the nature of the relationships e.g.

* conflicts between the immediate needs of the property developer and the broader needs of the community (and the property developers desire to circumvent constraints)
* the technician's/tradesman's views that because they know more about the detail of some technology than the town planner (and architect) the town planner (and architect) don't know what they are talking about and don't add value.
* etc.

Architecture
EA is often compared to building architecture. I think this analogy is weak if not misleading. Even if EA was like building architecture a good architect does not start from scratch. The site (slope, location, views, noise, boundaries, egress, soil/sub-soil, drainage, vegitation etc.), and its services (electrical, roading, water, drainage etc.), then there are all the codes (which codify standards of interconnection, styles/patterns of construction etc. exist). The codes make clear that even an individual building is not built in isolation. Buildings will usually be built to specific support a set of functions, an organisation, sometimes extant furnishing/equipment/plant etc. It is true that sometimes building are built to support generic functions/organisations (but these are more analogous more to OTS SW).

(This analogy could be extended considerably)

People a key factor in EA.

2007-09-04T08:50:00.000+10:00

Many of the challenges in EA relate to people i.e. where people don't have the right motivations, capabilities, personality and background. One needs to assume of course that they are neither misologists nor misoneists (though sometimes this is hard to assume based on the evidence and the attachments to tools/mechanisms that they have long used without any obvious success - see http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html; http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html).

The comments below on capability and personality type come from research I have recently read.

Motivation
In many cases people don't have the motivation to see EA done properly

self-interest: if my knowledge represents my value then why should I share it? And if everyone can share knowledge without me - why do they need me.
insecurity: if my judgements are based partially on gut instinct (to be charitable) or blind prejudice (to be uncharitable) I don't want my judgements to be examined critically i.e. the basis on which I reach my conclusions (develop my plans and strategies).
secrecy: frequently people don't want to disclose their plans or strategies because it allows people to oppose them. Usually within the organisation this is counter productive.
laziness: thinking is hard, takes time and effort, and if I can wing it - then that may be easier.
mypoia: I am judged based on this years projects/results (not how well it works when I am gone).

Capability or way of thinking
EA's should:

be visionary and be able to conceptualise
be able to analyse and problem solve
show business acumen and be aware of situational politics
Most importantly be able to communicate - and perhaps not annoy with their constellations of abilities ;-)

It seems that IQ is a key determinant, along with communication skills, business knowledge, problem solving and attitude towards time (i.e. re the future). Not age, intuition, technical skills.

Personality type
EA's should be: creative, open minded, passionate,engaging and resilient

Background (knowledge, skills and training)
It is useful to have had a broad background i.e. technical (hardware, software, services, applications etc.) and business (sales, marketing, operations) and to have had training in design (engineers, architects etc.) and communications. To have developed this breadth of background takes time.

To often an EA is criticized by some point technologist for not understanding the specific domain of the point technologist well enough. This is common criticism of architects generally.

The Peter Principle and EA.
When an organisation doesn't have hard and concrete measures of function (e.g. EA) the "Peter Principle" often comes into play.

Often the EA will be well respected within the Enterprise in an abstract kind of way (i.e. people will say "he knows a great deal about our business and systems", "he is very smart", "he knows lots about technology") , but not in a concrete way (i.e. "we really know what he does, what he produces etc."). This usually presents an EA who has risen through the ranks of technologists to pop out at the top. They will think that EA is little more than an extension of the technology oriented role they most recently had (e.g. SW design, infrastructure design/CMDB, Business process design etc.).

Frequently these people are ill-suited to EA based on their cognitive/personality profiles and they don't have broad backgrounds (i.e. they are essentially technologists - interested in technology).

Conclusion
To be success in EA one needs someone with the right: motivation, capabilites, personality type and background. These people are hard to find. The capabilities and personalities are very hard to change - but it is comparatively easy to provide people training to supplement gaps in their background, and it is easy to set up measures that will adjust their motivation.

James Rogers Breakfast Presentation

2007-09-03T10:09:00.001+10:00

For those of you who missed James' breakfast sessions in Sydney and Melbourne, a copy of his presentation is available. Please email us at info@rhe.com.au for a copy.

One of his main points is that EA, and EA tools like Troux, are increasingly being viewed as a key enabler of business transformation projects. Without an aggregated view of an organisation it is very difficult to make data based decisions that span possibly multiple lines of business and IT.

From the perspective of Enterprise Architects, who often struggle for budget and to prove their value to the organisation, attaching EA to Business Transformation initiatives is a good way to prove the value of the process and to incrementally build out a view of the enterprise architecture.

James also showed us some highlights from the soon to be released Troux 7 products.

Guy

EA can't be done with document or CASE tools

2007-09-03T08:36:00.000+10:00

To be a success EA requires the correct tooling/technology. All reputable EA experts would recognise this (though some were slow coming to this fairly obvious conclusion).

What are some of the things a tool needs to do?

The correct selection of the technology requires a clear understanding of what is required. This includes:

Communicating- to a broad set of stakeholders (not aligned to any specific technology, and most not aligned to any technology). This requires communication in many forms (diagrams, forms, reports, documents etc.) and using many media. This in turn requires a range of publication techniques.
Accessible - if the information held in the EA is not accessible (e.g. via a Web portal) and searchable (i.e. based on the specific, and immediate, area of interest of the person looking for information).
Analyzable - one must be able to analyse the information (this requires that concepts and relationships are explicitly recorded.
Aggregating - the EA will contain data owned by many constituencies (people and systems) and it is necessary to be able to aggregate the information from the various sources. The systems include operational systems (e.g. CMDB), design-silos (e.g. ER models, UML models, BP models), and business people (with the plans, products etc.).
Maintainable - as a natural part of day to day activity i.e. without requiring any substantial additional work by any of the data owners.
Secure - reflecting who owns the data, and who can access it)
Auditable -
Consistent - so that if a change is made to a concept (e.g. a business goal, a technology component) it is reflected everywhere.
Integrated and cohesive - so that all connections known are recorded.
Explicit and precise - this requires that the semantics are able to be explicitly recorded i.e. the core concepts and the relationships between them (their types, properties, weighting, etc.).
Business oriented - this requires that languages suitable for communication with non-technical people be used (e.g. not languages just used by design people UML, ER , BP etc.).
Technically connected - this requires that the EA can represent the semantics that occur in the various technology design silos (UML, ER, BP, etc.) so that explicit connections can be made to things elaborated in related tools (e.g. CASE) and eventually leads to executable code.

What about people who say it can be done without tools?

If an EA professional advocates doing EA without suitable tooling - I would characterize it as unprofessional i.e. either they are ignorant (of what EA is, and what is required to achieve it) or they are being disingenuous (i.e. they know what is required, but don't see it in their interest to make it clear).

By way of comparison - if someone's profession was creating complex models in another domain e.g. large project plans, complex budgets, complex building design - they could not (in any of these domains) credibly advocate doing this just in say Powerpoint, Word or Visio (and at the same time claim to know a great about project planning, budgeting, complex building design).

What about an Office suite as a tool?

EA tools must have the detailed representation of information that BI requires, have the communication and ontological capabilities of knowledge management tools, be able to support the detailed semantics required for connection to dedicated design domains, and be able to graphically communicate complex designs.

Office suites fail for reasons such as:

Communicating - Documents can't practically be produced for each and every stakeholder focusing on the small subset of the information they are interested in at any point in time, and presenting it in precisely the way they want to see it (diagram, forms, report, chart) etc.
Analyzable - Documents (Word, Powerpoints etc.) can't be analysed (except by people)
Aggregating - Documents don't lend themselves to aggregating data.
Maintainable - no one can credibly suggest that all data held in documents is practically maintainable.
Explicit and precise - Documents seldom explicitly record all the relationships within them and never record all the relationships across concepts held in sets of them.

The information from an EA should be able to be conveyed via documents (from Office suites). In this sense these documents (Word, Excel, Powerpoint, Visio etc.) represent reports. However the fact that reports are required does not mean that the reports themselves are the locally repository for the data.

What about CASE tools?

People' who start looking for EA solutions by asking about CASE capabilities - indicate that they have not understood the essential nature of the problem see:
http://ea-in-anz.blogspot.com/2007/08/business-modelling-with-domain-specific.html
http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html

Business modelling with domain specific languages

2007-08-31T13:19:00.000+10:00

If one wants to make business modelling effective it is often useful to use domain specific modelling languages. If for example one is modelling an airlines it may be useful to model with concepts such as: passengers, cargo, baggage, flights, tickets. One could of course use generic business/technology concepts for these e.g. organisations or people (customers), products and services (e.g. flights), contracts (e.g. tickets) etc. And people do try and use abstractions of abstractions e.g. actors, objects., tables etc.

Effective modelling in a business language is also necessary for the establishment of reuseable patterns.

The further one abstracts the more difficult it is for the people to understand, and to build the intrinsic knowledge of the domain into the model/artefact. This is why you won't see many good documents written by business analysts using overly abstract concepts (or any executive level documents) e.g. actors, objects, rows, tables etc.

What one needs ideally is an environment that allows domain specific semantics to be quickly instantiated - inheriting from abstract objects as appropriate i.e. passenger is a type of person (has name, address etc.), to be able to model using these semantics and relate all modelling concepts together when it is useful e.g. domain specific, generic business/technology, and various technology specific abstractions.

These domain specific languages are aimed at people interested in the domain (the business) i.e. business users and analysts. They would be used in preference to the "unified" and technology oriented languages foisted on the business by the development community.

Obviously design oriented languages should be used by systems' designers (e.g. UML, BPML, ER, XML etc.). As they form a useful common abstraction point between the technology specific languages used by developers (there will often be many of these).

These languages act as bridges between the business domain specific languages that most appropriate for business modelling and the technology specific languages that are used for construction. They provide an articulation point between the business domain and the technology domain. This articulation point is required: to allow design for construction with a heterogeneous/open technology set i.e. where there will be range of technology specific implementation languages (many of which may not have been selected/determined when the business modelling is undertaken) ; and to allow aspects of design modelling to transcend the specific technology implementation selected. Design involves decisions regarding what implementation technologies to use and therefore one does not want to prematurely lock the design thinking to implementation (unless one is a technology product vendor seeking to "capture" the customer). If one was designing a beam - one would often want to know the characteristics of the beam (by modelling) before determining if the beam should be wood, steel, concrete, a truss etc. or a particular brand of style of steel beam (i.e. in this case these are the implementation technologies).

Even organisations with a strong historical alingment to UML (and MDA whose current implementation is unfortunately predicated on UML) are moving to DSL to overcome the complexity (and unnecessary abstraction) that UML involves e.g. Borland is adding domain-specific language capabilities to Together package for application modeling to enable project teams to build model notations aligned with a business domain. This is not to say that UML has no place - it is fine for technical people to communicate amongst themselves - you just can't reasonable inflict it on non-technical people (or pretend it is well suited to capturing business requirements).

See: UML not suited to describing the architecture or an enterprise

Business and IT Transformation

2007-08-31T13:02:00.000+10:00

The term "EA" has developed some unfortunate connotations e.g. it has been confused with "technology architecture", "systems architecture", "solution architecture", "software architecture", "business process modelling" etc.

This is reminds one a little of the famous strong of the "blind men describing the elephant".

If one uses the analogy of town planning - it is a bit like confusing town planning with: architecture, electrical installation, landscaping, interior design, plumbing etc. When asking for a tool selection to support townplanning - one is then asked if it has a electrical load modelling capability; hydrological modelling capability; a lighting model for examing interiors, or a CAD tool for drawing beams [see http://ea-in-anz.blogspot.com/2007/09/ea-and-analogies-with-built-environment.html]

In EA at present one is often asked if it the EA tool is a CASE tool (ER modeller) or process simulation tool - and what this illustrates is that the person asking the questions does not a good grasp of what EA actually is. [see http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html]

EA also is often seen as some ivory tower activity that at best produces lots of large complex documents (that always out of date, and that are of little value to anyone other the authors) - mainly because EA is done in the wrong way.
[see http://ea-in-anz.blogspot.com/2007/08/myth-of-heavy-weight-ea.html]

It may well be that the pragmatic way around this is to abandon the term, and the
focus on the end goal which is business and IT transformation.

UML is not a language suited to most aspects of EA

2007-08-24T11:55:00.002+10:00

(prompted by discussions with EAs and "How UML is Used")

UML is often one of the first words that comes out of IT people's mouths when one discusses EA (in a bizarre attempt at logocide one organisation evens call its UML modelling tools Enterprise architect).

UML clearly very useful, but not for most aspects of EA. This is because most of EA has little to do with modelling oriented OO development (or SW development and per se) and because UML is effective at communications with business people (i.e. not technical people).

The analysis that needs to be done in EA is not really related to the different states that objects can exist in, the messages that objects used to communicate, or low level "use cases". Obviously an EA needs to consider scenarios of use (how things are used in different situations by different people) - and one could use the oddly named "use case" mechanism for this - however many other mechanisms are available and my experience is that a great to alienate most business people is to start of by using abstract terms like "actor".

That people attempt to apply UML to enterprising architecture probably indicates the mistaken belief that EA is somehow an extension of software development - and goes a long way to explaining why some many EA initiatives fail.

There are various aspects of detailed SW design oriented analysis that we may wish to relate to from an enterprise architecture or we may wish bring together for analysis the disparate views of various development silos e.g.
- process orchestration development views which use BPEL that may relate to BP models
- object development views which may relate to UML models
- data development views which may relate to ER models
etc.
This is more in the solution architecture rather than enterprise space. What an EA can do is bring together these disparate silos.

We could also consider the broader issue of the utility of UML in capturing requirements per se.

In "How UML is Used" by Brian Dobing and Jeffrey Parsons - it seems reasonable to assume that as the data references in this article is gathered from UML practitioners/clients they are not unreasonably prejudiced against UML. What bemuses me is that the authors - despite the facts in front of them - doesn't seem to just say "UML is not great for client facing requirements capture" or for communicating with non-technical audiences. This doesn't mean UML may not be great for technical communications e.g. between designers and developers.

What can we learn about "How UML is Used" regarding requirements capture?
- UML may be too complex for clients (no kidding) and those who are not technical (i.e. who don't want to participate in development).
- UC are not thought that good for communicating with clients (business people)
- Clients (business people) don't want to review the artifacts beyond UC narratives (and why would they, when these are really development/developer oriented models)?
- UC diagrams are rated as least useful in providing additional information to developers.
- Despite the above developers, undeterred, seem to believe that UML diagrams can be understood by clients?

Contrary to claims in the popular literature, developers appear to believe that UML diagrams can be understood by clients. 87% of respondents rated UC Narratives as useful for "verifying and validating requirements with client representatives on the project team.", but when asked whether the UML facilitated communication with clients, 55% said it was at best "Moderately Successful."

Domain specific business languages (or Enterprise specific languages) may be a better answer. To instantiate these dynamically so they are available for modelling, one needs a metamodeller.

EA requires an ability to communicate on many subjects with a diverse range of stakeholders. Selecting an arcane language oriented at object oriented analysis is unsuited to the task i.e. both the semantics and the notation are a poor fit for the vast of the information used to describe an enterprise.

If UML struggles to capture the requirements for project in which development undertaken (i.e. to act an effective mode of communication) - surely people can see that if the task is describing an enterprise (where development is not the major goal i.e. it is a necessary evil) - it is unlikely to be a good fit.

Of course long before this Anthony J H Simons, Ian Graham wrote about: 30 THINGS THAT GO WRONG IN OBJECT MODELLING WITH UML 1.3. In this the authors catalogue problems experienced by developers, using various object modelling techniques brought into prominence by the widespread adoption of UML. Developers still seem to create inordinate problems for themselves by pursuing unproductive development strategies that are apparently fostered by UML. This article shows how the biggest problem by far is cognitive misdirection, or the apparent ease with which the rush to build UML models may distract the developer from important perspectives on a system. This problem is more serious than the outstanding inconsistencies and ambiguities which still exist in UML. While UML itself is mostly neutral with respect to good or bad designs, their are consequences of allowing UML to drive the development process.

The cognitive misdirection problem is more serious when UML is applied in domains other than OO design. In these case the pursuit of unproductive strategies oriented around UML can only consider "the triumph of hope over experience" (Samuel Johnson).

The myth of "heavy weight" EA

2007-08-24T07:29:00.001+10:00

There is a common myth that maintaining an effective EA introduces a lot of cost to the Enterprise. An EA implemented in the right way reduces the level of effort and cost in an enterprise overall.

An effective EA needs to be supported by the right tools, and the right changes in associated processes (each of these processes in turn becomes more efficient and accurate) and be comprehensive in the set of stakeholders it supports.

A "Light weight" EA - where a superficial and partial set of information is assembled in the traditional way (i.e. without the right tooling, and without changing the touch point processes) may suit "light weight thinkers" - but as they fail to deliver substantial value and they add additional cost - they don't make any sense.

Establishing the changes in an enterprise that will allow an effective and complete EA to develop (and establishing the tooling, and changing associated processes) does have a cost but this cost is comparatively small if led from the right level within the enterprise, undertaken over a period of time (i.e. most cultural change is hard to effect quickly).

By way of one imperfect analogy - books and libraries
Assume your current strategy for managing books (i.e. knowledge - putting aside for now the fact that documents - especially in narrative form seldom make the semantics explicit, or relate knowledge in one book explicitly and atomically to knowledge in another book) is to leave the books scattered all over every office (and this is the form i.e. documents, and is the strategy essentially advocated at present; for most the design/governance artefacts associated with an enterprise).
Most people would find it quite difficult to find the correct information on most subjects, and if they wanted to record new information about subjects so that others could find it they would not know where to put it.

Say a proposed strategy is to establish a library function e.g. a classification system (Cf Zachman's framework), some places (physical or virtually) and some simple processes (that you would like people to follow). Now the actual cost of finding knowledge on any subject (i.e. what is said by a range of authors, with different perspectives) is reduced, and knowledge on subjects can know accrete in a natural way. Yes there is a set up cost.

A problem with this analogy is that most of the documents created in an enterprise are created by their authors for a very small and select audience (which in itself is odd), whereas most authors of books would ideally like their readership to be as broad as possible.

Another imperfect analogy - maps and the environment (built and natural)
If your current strategy for managing information about the environment (from rivers and mountains, to buildings and reticulation systems) is to leave documents scattered all over a wide range of offices/enterprise (and this was the form that the various stakeholders used until very recently). And a proprosed strategy is to establish a mapping function e.g. a classification system (a co-ordinate system, or a map projection), a collation mechanism and processes. The actual cost of finding out about any areas is reduced, and knowledge (on all areas) can accrete in a natural way (i.e. as the plans on buildings, cables, new information on soil types, etc. are deposited). Yes there is a set up cost.

No new information needs to be created - and in fact the effort associated with creating meaningful new information is reduced (e.g. it is easier to design changes if I can see clearly what already exists - buildings, cables, geological structures etc.) at the start of the exercise - rather than as I start construction (which is the ICT industry's approach).

Many artefacts are created by a function or unit for a very specific purpose and for a very small and select audience. The artefacts are usually focused on a narrow task (usually related to some delivery and/or construction activity), and specific timeframe (e.g. usually the immediate future). They are not oriented at: the ongoing maintenance, the effect on others, their discovery in future, the eventual replacement of what they is being delivering etc.). Governance (town planning functions) is slowly overcoming the impediments that the various engineering and cartographic specialists put in the way of this knowledge base by organising and sharing that knowledge.

SOA must be underpinned by better management

2007-08-23T10:10:00.000+10:00

Most people know SOA is widely over-hyped (mainly by vendors seeking a new label to sell last years goods under, and ICT people who see a new set of technologies they can focus on rather than engage with the business). How on earth can we move to a more sophisticated, atomic, externalised, real-time view of services (lets forget about technologies and standards for now) - when the current management of services - which are simple, large-scale, mainly internally controlled, and seldom adjusted in real-time - is just typically pitiful (from requirements, through design, to implementation, operations and measurement).

In a CIO presentation on SOA in early 2005. I discussed the business drivers and technology enablers for SOA, the design challenges (perennial and new). It was drowned out the superficial presentations focused on irrelevant discussions around a plethora of technologies and standards.

I identified some things that make it hard e.g.

absence of a well articulated technology vision
tightly coupled, poorly bounded, systems producing fragility and insecurity
technical fiddling with OTS components so that systems overall are expensive to maintain
poorly managed outsourcing [i.e. the management of services]
orienting technology architectures around systems/vendors/products/technologies rather than around the business and standards
descriptions of the business that were incomplete, incoherent, inconsistent, inexplicit.

I suggested that the challenges are largely the same as they have been – but failure may become harder to hide (i.e. perceptions of the quality of businesses may be based on how well their systems perform).

That SOAs don’t present many overly difficult problems to well architected and managed enterprises, but that SOAs may be less forgiving to doing things in ways that have worked in the past (though they are not best practice).

To support my call for more professional and better management of complexity - I quoted British computer society "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... Whilst the most pressing problems relate to the people and processes involved in complex IT projects, 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..."

To point out how little has changed I referenced what was said on architecture in a IBM systems journal from 1999:

“Today, the most common model for solution development is based on an approach that we call ‘heroic’ ”.
Goals: contain costs and risks, providing timely, adaptable, and customizable solutions.
Challenges: complexity: driven by new technologies/standards; legacies; many applications/services; unique customization; external relationships (i.e. business network) change: a high rate of both business and technological change.
Suggestions regarding the solution: patterns: a standard framework to support creation, reuse, and maintenance of design assets; discipline applied: to allow practitioners to base their development on patterns; reuse: of proven building blocks, applied systematically to enable asset-based solutions optimized to business goals. focus on: component topologies/interactions & management of: security, systems, performance; combine: HW, SW, products, assets, and services; establish: business reference models, default infrastructural templates/frameworks, contextual map for cataloging assets and knowledge, clear methods for making decisions

To indicate my dispair I quoted Hegel "what experience and history teach is this - that [we] have never learned anything from history, or acted upon any lessons they might have drawn from it". Though I would rather believe William Blake "Truth can never be told so as to be understood, and not believed"

Justifying architecture and strategy

2007-08-21T10:48:00.000+10:00

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

Counterfactual reasoning prevents proof of value: In most situations (enterprises, buildings, cities, endeavours), one can't easily compare the result of the designs/strategies/plans that was actually taken - with hypothetical other design/strategy/plan that could have been taken. People either need to intuitively value sound well reasoned designs, strategies, plans - or not i.e. the ROI is either obvious or it is not.
Self-interest: This can militate against sharing knowledge. Knowledge is power. This can be seen in many professions to a greater or lessor extent. If ones shares and/or make available the knowledge one has (or the basis of a decision), one may diminish ones value (as a holder of knowledge), and become open to 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).
Thinking is intrinsically difficult: These things (strategy/design/planning, and modelling) are often quite difficult to do well i.e. they require quite a lot of thought. To make matters worse the result can be seen, with hindsight, as trivial and not justifying the effort required.
Thinking takes time: It is always quicker just to act
Thinking costs money: As results may be seen as trivial e.g (F = M x A) and could not be worth justifying the effort.
Future is someone else's problem: That what is constructed is a poor fit, doesn't last, is expensive to operate, expensive to change or adapt is often not the problem of the initiator, the initial designer, or the builder (and perhaps the initial user).

These issues can be seen all areas of life e.g. social planning, cities, buildings, cars, and of course businesses and Information and Communication Technology (ICT). ICT is particularly bad as it has not yet matured into a profession (where people have the requisite learning, training and discipline and profess a 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.

Michael.

James Rogers comes to Australia

2007-08-15T12:29:00.000+10:00

We are please to have James Rogers, the Chief Marketing Officer of Troux, visiting Australia in August.

James recently authored the cover story of Architecture and Governance magazine, "The Evolution of EA".

He is speaking at breakfast sessions in Sydney on Wednesday 29th August 2007, and in Melbourne on Thursday 30th August, and his subject will be "The State of EA in United States and Europe".

If you are interested please contact us on +61 2 9900 4100 and we will give you the details.

Guy

Welcome to EA in ANZ

2007-08-15T11:52:00.000+10:00

Welcome to this first post on EA in ANZ.

This Blog is intended to share information and ideas on the practice of Enterprise Architecture, and be a source of information for the user group of the Troux / Metis EA toolset.

We will endevour to keep people up to date with the latest developments and share ideas, techniques and other interesting bits of information as they come up. We encourage you to subscribe to the RSS feed of this Blog so you can see when we have posted something new.

Guy & Michael