The Standish group report

The CHAOS Manifesto concluded that 74% of projects were delivered late, 59% over budget and they ONLY delivered 69% of the planned features!

The top two reasons for project failure Why Do Projects Fail? And (http://calleam.com/WTPF/?page_id=799) identified : underestimating the complexity and cost and the control and management of requirements.

The role of the Enterprise Architect is fundamental in assuring that projects are scoped correctly and that they deliver on their promise (deliver the right context). Will Enterprise Architecture save US companies US$80M a year in failed I IT projects? (See CHAOS Manifesto), and what are the key characteristics of the Enterprise Architect that will stop 30% of my IT projects failing?

These question have been perplexing FEAPO (Federation of Enterprise Architecture Professional Organizations) who are developing the careerpath and identifying the key skills of Enterprise Architects over the last year.

One key skill of the Enterprise Architect was debated at length : Elicitation.

Coming from an ICT background I have been aware of the need to gather and redefine requirements. I am a great advocate of Volere as a requirements method and approach.

There are already good definitions of elicitation. Traditional systems thinking and requirements analysis have developed techniques for eliciting for a purpose.

Although there are others who believe more is required (see here). This last reference echoes back to the challenge of requirements in project failure identified in the CHAOS report.

There are some lessons to be learnt from other established users of elicitation techniques e.g. The Federal Bureau of Intelligence elicitation techniques. Then again, some within the careerpath working group felt this may be going one step too far!

Here, I thought back to the day that I announced that I was bringing in police hostage negotiators to train my architecture team. There was surprise from my fellow directors that we may be taking a more aggressive stance! Others felt the architects had been taken prisoner! How would I now explain training by the FBI? !!

There is another reason that elicitation has to be a key skill for the Enterprise Architect today. Enterprise Architecture, as a discipline and a science is very new, less than 40 years old. The term “Enterprise Architect” in the IT industry means everything from someone who deploys 5000 desktop portable computers, to someone who can synthesize what the business is doing, what competitors are doing, incorporate plans for growth and specify the capabilities needed to make a profitable business. With such disparate views of enterprise architecture, the Enterprise Architect must support stakeholders in realising how enterprise architecture can benefit them, what it can’t do, and take those stakeholders on a journey of understanding.

So what about Big Data Analytics ?

An enterprise architect, and those in the requirements process, meet questions that are uncertain. Solving uncertainty requires a facilitated group of experts to shape, share their knowledge, and provide opinion. This can be a simple matter of bringing those subject matter experts into a room, or it could be as diverse as polling all technicians of all parts of a product (e.g. a car) both inside and outside the company to understand the dynamics of a fault.

The role of enterprise architecture elicitation is about knowledge gathering and helping participants prioritise and rationalise the knowledge that has been gathered. There are a number of specific scientific areas that Enterprise Architects may need to consider as tools to gather and judge information as part of that elicitation process e.g. Uncertain Judgements: Eliciting Expert Probabilities.

Here these techniques can be broadened to consider broader social engagement, not only of experts, but other opinion shapers. Within customer analytics, fraud and financial crimes, there is a constant need to re-evaluate the risk and value from effective customer engagements. For financial institutes all three of these intertwine, perplexing users, marketeers, operations, fraud, compliance and financial forensic experts about how to baseline and re-calibrate the risk and financial exposure to their business.

With the rise of the internet and social media, organisations turn to more diverse opinions on the product and services they provide. Blunt instruments like opinion polls and scanning twitter feeds are no longer sufficient for leading edge organisation. There is a need for wider social engagement and elicitation of information. Here enterprise Architects need to identify the change and maturity of processes required within the organisation and also help incorporate a Big Data engagement process to continually evaluate the effectiveness of the customer engagement, and recalibrate the user engagement. Here eliciting information from large groups http://www.eea-esem.com/files/papers/EEA/2010/1605/SamplingFeb.pdf , uses Big Data analytics, to feed the questions that help organisations deal with complex uncertainties.

The conclusion

The final definition of elicitation will be published as soon as the careerpath for enterprise architecture is produced. It is currently within its final revisions. For those interested in a career in enterprise architecture it will provide valuable insight on agreement across the FEAPO member organisations.