Thursday, December 13, 2007

Linking SW Architectures with Enterprise Architectures

(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

Thursday, November 29, 2007

Model driven SOA


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).

Thursday, November 8, 2007

Modelling Business Strategy

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

(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 ).


Tuesday, October 30, 2007

Ehancing EA with SOA

(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.



Friday, October 26, 2007

EA for SOA (CBDIForum)

(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).

Tuesday, October 23, 2007

SW Architecture feeding into Enterprise Archiecture

(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.

Monday, October 15, 2007

Business and IT transformation

(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



Wednesday, October 3, 2007

Improving IT's reputation and alignment

(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.


Thursday, September 27, 2007

Why don't most IT processes work well

(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 well. 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]

Tuesday, September 25, 2007

Troux 7 Released in the USA/Europe

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)

Friday, September 21, 2007

Data Governance - Maturity Model


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.

Thursday, September 20, 2007

Thinking SOA (are the issues really that new?)

(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?

Saturday, September 15, 2007

EA and SOA shareholder issues?

(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




Friday, September 14, 2007

Enterprise data management

(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 not 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).

Tuesday, September 11, 2007

CIO key to business and IT transformation

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

Monday, September 10, 2007

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

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)

Wednesday, September 5, 2007

EA and analogies with the built environment

(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
  • Property Portfolio Manager - Enterprise Portfolio Manager
  • 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)

Tuesday, September 4, 2007

People a key factor in EA.

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.



Monday, September 3, 2007

James Rogers Breakfast Presentation

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

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

Friday, August 31, 2007

Business modelling with domain specific languages

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

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.

Friday, August 24, 2007

UML is not a language suited to most aspects of EA

(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 may be very useful, but not for most aspects of EA. This is because most of EA has little to do with OO modelling oriented at OO development (or SW development and per se) and because UML is just not effective for communicate with most of the business (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 technical "use cases". Obviously an EA needs to consider scenarios of use (how things are used in different situations by different roles or systems). And one could use the very oddly named "use case" for this, however many other mechanisms are available usually better suited to use in EA. In my experience the quickest way to alienate most business people is to start of by using abstract terms like "actor", or talk to them Swedlish. Most people in the business prefer natural business concepts like: business process, business role or organization, etc.

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. For example we could consider the relationship between a business process or a business role/organization, and a business application (and elaborate that relationship using UML - if it really added value). But for most people getting a canonical list of business processes or business applications would be a great starting point - rather than elaborate great detail one interaction

We could also consider the broader issue of the utility of UML in capturing requirements per se. UML is also often also one of the first words that comes out of IT people's mouths when one discusses business requirements.  This is mostly the case when IT people with a SW engineering background are involved. Or when executives want to show they an "in" with technical people by using their arcane terminology,

UML not useful for most, if any, aspects of business requirements management. Business requirements may result in software development (the majority will not). Of those that do require development only a subset will require OO (e.g. others may require BI). Often when development is required it will be outsourced or done under contract. What the business needs is boundary of responsibility that allows those solutions elements delivery to be assessed.

By way of analogy. If one has transport requirements - one doesn't to be asked what use case of a brake pedal is. One wants either a transport solution (streets, tracks and trains, roads and vehicles, ships and ports), or a services (e.g. buses, taxis), or possibly an in-house asset car, a bike, a plane. In the rare circumstances where a car is engineered for a client - it would be a very brave (or foolish) client indeed who would try to specify it, or its components, using Use Case, Sequence diagrams.

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).

See www.semanticprecision.com for a better solution.

The myth of "heavy weight" EA

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.


Thursday, August 23, 2007

SOA must be underpinned by better management

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"

Tuesday, August 21, 2007

Justifying architecture and strategy

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.:
  • Challenges with counterfactual analysis: in most situations (enterprises, buildings, cities, endeavours), one can't easily compare the result of the designs/strategies/plans that was actually taken - with other hypothetical designs/strategies/plans 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. So there is no point of comparison.
  • 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.

Wednesday, August 15, 2007

James Rogers comes to Australia


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

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