SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Evolutionary Development Methodology® is a registered trade mark or Redwing Business Intelligence Ltd.
This presentation is a brief introduction to EDM®
It describes the essential concepts.
EDM today is specifically for business intelligence.
The quote is from a guy by the name of Alistair Cockburn. He wrote a book called Agile Software Development: The Cooperative Game in 2002. He’s a very respected guy in the agile methodology world. He’s a big wheel.
But notice . . . his focus is software.
<click> Redwing, on the other hand, describes Evolutionary Development Methodology® in terms of ‘delivering value to the business’. We don’t mention software at all.
Methodology, to us, means:
what we do, the order we do things in, our architecture, our technology, our organisation and staffing, and most importantly, why we do things that way.
EDM® is complete. It starts at initial business need, and on the way to product delivery, it encompasses everything from project management to job descriptions.
To re-iterate, our focus is all about delivering value to the business, not systems or software. We are not primarily technologists. We use technology as an enabler to deliver value to the business, but it’s not intrinsically important to us. We are really good at it – we have to be - but we don’t actually care about it.
One last point: “around here”. It is our expectation that EDM® will be customized by every enterprise that uses it to better fit local needs and practices. One size does not fit all. The detailed documentation describes possible customizations, and in particular, it defines both a lightweight and a formal version of EDM®
OLTP stands for Online Transaction Processing and is the bread-and-butter of computer systems.
A patient administration system is an example of a Transaction Processing system. An incident recording system is an example of a Transaction Processing system.
An Incident Analysis system, that provides an overall picture of the state of patient safety, perhaps with trends and predictions, is a business intelligence system.
Because the Deming Cycle (Plan-Do-Check-Act) is continuous, and never-ending, so is the need for actionable information i.e. business intelligence)
If you take the
In the beginning, there were no methodologies. Programmers just wrote programs.
As development projects grew larger, so did the need for manage and control them.
The Structured Development Life Cycle (SDLC) was invented. The essential philosophy was that everything that’s needed to be known, can be known and specified up-front. Software development proceeded in phases; each phase had to be reviewed signed-off by the customer before the next phases could be initiated. The intent was to limit risk by exercising maximum control.
<click> Over the last fifteen years or so, the so-called ‘Agile’ school of methodologies have emerged. These came about as a reaction to the structured waterfall methodologies, and emphasise a focus on product delivery, rather than micromanaging the process.
What these have in common is that they’re used by a team of people in the creation of a single product. The tools are typically third generation languages like C++ or Java, which are used to produce coded systems. Scrum, for example, has daily meetings of the programming team who are all focused inwardly on the single software product under development.
The focus in business intelligence is quite different. BI programmes are business programmes, not technical ones. The focus is on the business, the business user, the business process . . . and not the technology. People mostly work independently on their own separate and largely independent pieces of the overall solution. The tools are largely graphical. There’s very little actual computer code. This is very, very different from Scrum, for example.
<click> Now, take a step back. A decade before ‘Agile’, there was Spiral. (Somewhat forgotten, today)
In the 1980s, people searched for alternatives to SDLC waterfalls, because they were not working. Systems delivered late, way over budget, and most importantly, not meeting user needs, nor focused on delivering value to the business. (Things haven’t changed!)
So people like Barry Boehm and Donna Kelly (one of the Redwing principals) came up with the Spiral model. Donna Kelly was heavily involved with the use of prototyping to deliver systems with Fourth Generation Languages like Focus. She evolved spirals and prototyping into the first generation of EDM® It was used to develop substantial OLTP systems for the Oil and Gas industry, and EDM® was sold to organisations like Alberta Government and Texaco.
The key part of this was the prototyping cycle. Product development was done on the users’ site, with the user as an active and involved partner. This was critical to success, and remains intrinsic to EDM® today (which itself has been through multiple cycles of evolution).
<click> Redwing believes that business value is best delivered in discrete chunks; we call them Releases. EDM® is spirals within spirals. The Release is the outermost spiral.
There’s a document, The Origins of EDM®, that’s available for anyone interested in how EDM® evolved though numerous iterations into the full-fledged methodology that it is today. You can find it on SlideShare.
In the mid-80’s, Donna Kelly spent much time working with Fourth Generation Languages and Prototyping.
This work culminated in the first iteration of EDM® and its product launch in 1988,
<click> She gave a speech to an audience of over 300 senior executives at the Management Stream of National Congress in Canada. The speech opened by asking the question, why do we need another methodology. What’s wrong with our SDLCs? <click> She quoted the first two lines, then explained that by superhuman efforts, the system was delivered. So far, so good, no? <click> No! She quoted the last two lines.
And that’s why we need a methodology that intimately involves the user in a step-by-step towards product delivery.
FYI, the full ditty is in the notes pages. ________________________________________________________________________________________________________________ ’Twas the Night Before Implementation
'Twas the night before implementation and all through the house, Not a program was working not even a browse. The programmers hung by their tubes in despair, with hopes that a miracle would soon be there. The users were nestled all sung in their beds, while visions of queries danced in their heads. When out in the machine room there arose such a clatter, I sprang from my desk to see what was the matter. And what to my wondering eyes should appear, but a super programmer (with a six-pack of beer). His resume glowed with experience so rare, he turned out great code with a bit-pusher's flair. More rapid than eagles, his programs they came, and he cursed and muttered and called them by name: On update! on add! on inquiry! on delete! on batch jobs! on closing! on functions complete! His eyes were glazed-over, fingers nimble and lean, from weekends and nights in front of a screen. A wink of his eye, and a twitch of his head, soon gave me to know I had nothing to dread. He spoke not a word, but went straight to his work, turning specs into code; then turned with a jerk; And laying his finger upon the "ENTER" key, the systems came up and worked perfectly. The updates updated; the deletes, they deleted; the inquiries inquired, and closings completed. He tested each whistle, and tested each bell, with nary an abend, and all had gone well. The system was finished, the tests were concluded. The users' last changes were even included. And the user exclaimed with a snarl and a taunt, "It's just what I asked for, but not what I want!"
Evolutionary. Each chunk of business value provided to the business – each Release – builds upon previous work. Each outer spiral iteration adds new business value to the business.
Incremental. In all respects, EDM development work is step-by-step.
Collaborative. The work is driven by business needs and information consumer requirements, with the business user playing a vital part of the development process.
Iterative. Each inner spiral iteration adds value to the work being delivered
EDM® is flexible and responsive, capable of being ‘steered’ at both the strategic and tactical levels, and therefore indeed agile.
However, in recent years the word agile has taken on an additional meaning.
Agile (capitalized) refers to for a specific set of methodologies for team-based coded systems development. Coded systems are systems programmed (coded) with a third-generation coding language such as C# or VB.NET. Such development efforts typically involve teams of 5-15 technical staff collectively focused on a single piece of software. Examples include Extreme Programming and Scrum.
The rhythm of these approaches is very quick, the daily scrum for the programming team, for example.
EDM® does not fall into this class of methodologies. It is a spiral methodology intended for business intelligence solution development using tools such as SQL Server Integration Services and Reporting Services. It’s agile insofar as it’s flexible and easy to steer the programme, but it’s not one of the capital-A Agile methodologies.
The rhythm of EDM® is slower, it beats to the heartbeat of the business, delivering a chunk of business value – a Release – every three months or so. This pace matches the ability of the business to work intimately with the business intelligence programme. (and the ability to the programme team to deliver Releases).
Methodologies such as Scrum are not appropriate for business intelligence development.
Every business has business processes. Each business process generates events of interest
For example, you’re a retailer , and you run stores. Today, I bought a dress. That’s an process of interest to the business.
That thing that just happened? That sale? That’s a fact.
Facts are associated with numbers.
The gross price was £89 The sales tax rate was 20% The net price was £106.80 The quantity was 1
There are 4 things I can add up, or putting it another way, the Fact has 4 Measures
I now have raw data that I can aggregate and turn into actionable information.
Facts are associated with numbers. The sale event was of a dress. The gross price was £89 The sales tax rate was 20% The net price was £106.80 The quantity was 1 There are 4 things I can add up, or putting it another way, the Fact has 4 Measures
The heart of the methodology is spirals within spirals.
The Release is the outermost spiral.
The original catchphrase from 1988 was ‘the user in control’.
The phrase knowing how we’re doing was the catchphrase of the NHS Productivity programmes that came out of the Institute for Improvement and Innovation.
This is considered absolutely fundamental to any performance improvement.
Knowing how we’re doing is the crucial first step.
It is why business intelligence must be used to underpin any performance improvement programme.
Evolutionary Development Methodology® is complete. It contains all assets required to create a greenfield BI programme.
Assessment asks the questions around Business need Utility of a business intelligence solution Costs and benefits
Initiation defines six steps to set up the business intelligence programme, including Governance Prioritisation Technical analysis
The key governance document is the Release Strategy. This is the overarching control mechanism for executive management of the programme as a whole. It outlines the contents of each Release i.e. each BI Project that contributes business value in its own right.
Each individual Release has its own detailed Release Plan.
There are spirals within spirals within Releases.
Understanding that the text is too small to read, this slide is available in the accompanying notes pages.
That said, here are some of the components (read a few boxes)
A foundation component of EDM® is the total architecture.
This is a principles-based layered architecture, and a fundamental part of EDM®.
It’s important to note that after twenty years, we now know how to build BI systems. It’s now engineering, no longer a craft or research project. We follow the cook-book, and three months later a business intelligence Release pops out of the oven.
The next slide shows the scope of one of the layers in this stack,
Again, understanding that the text is too small to read, this slide is available in the accompanying notes pages.
That said, this what a total Microsoft technology stack looks like.
This stack is actually only two suites of software – SQL Server and SharePoint. However, there are a lot of skills involved in using these suites effectively.
BTW, both SQL Server and SharePoint are Enterprise editions; we need the features.
A foundation component of EDM® is the organization design.
The design of the business intelligence organization reflects the underlying architecture of Business Intelligence itself.
In the first instance, data is taken from source systems and transformed into pre-digested information, held in a data warehouse of aggregated and pre-calculated metrics. This is a technical world of bits and bytes. This inward-facing world is where the technical people live. This matches the blue on the left of the Technical Scope diagram.
Data warehouse metrics are then available for processing by Reporting Services, PerformancePoint, Power View and so on, to create a wide variety of reports for business user consumption. This is the world of business intelligence report creation and information consumer liaison. This outward-facing world is where the information analysts live. This matches the green on the Technical Scope diagram.
The programme manager is responsible for tying all this together.
Alberta Government (several departments)
Greater Manchester West (Mental Health Trust)
We Buy Any Car
Queen Elizabeth Hospital (Acute Health Care)
London Commissioning Support Service (Primary Health Care)