Evolutionary Development Methodology
•Download as PPSX, PDF•
3 likes•2,079 views
EDM is an agile, spiral methodology developed specifically for business intelligence. It is a complete end-to-end methodology including assessment, initiation, and delivery. EDM incorporates a principles-based layered architecture, including business architecture, information systems architecture, and techology layers.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Evolutionary Development Methodology
Similar to Evolutionary Development Methodology (20)
More from Donna Kelly
More from Donna Kelly (10)
Recently uploaded
Recently uploaded (20)
Evolutionary Development Methodology
- 1. © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Evolutionary Development Methodology® for Business Intelligence Introduction Slide 1
- 2. What’s a Methodology? • Alistair Cockburn describes a methodology as: “everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.” • Very differently, Redwing describes EDM® as: “this is how we do things around here, to deliver value to the business” © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 2
- 3. BI is not OLTP • Transaction Processing systems are typically marked by a large development, followed by implementation into production and a much smaller maintenance effort • Business Intelligence is utterly different: it is a never-ending story, with continuing evolution and no differentiation between development and maintenance • BI needs a radically different methodology © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 3
- 4. Methodology Roundup • Traditional Waterfall: the SDLC – Pride, Spectrum, SDM/70, PRINCE 2 • ‘The Agile Manifesto’ 2001 – Extreme Programming, Scrum • Spiral – Boehm, Du Pont, EDM® • The Release is the outer spiral of EDM® © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 4
- 5. 1988 – Christmas in Toronto National Congress Canadian Information Processing Society 'Twas the night before implementation and all through the house Not a program was working not even a browse. - - - And the user exclaimed with a snarl and a taunt, It's just what I asked for, but not what I want! © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 5
- 6. Principles of EDM® • Evolutionary • Incremental • Collaborative • Iterative • Agile? © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 6
- 7. Processes: the heart of the business • Business run on processes • Processes generate measureable data • Measuring that data means turning raw data into information • Good information is actionable information • Actionable information lets the business improve its processes © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 7
- 8. Releases: the heart of EDM® • The focus is delivering value to the business • Value is delivered in chunks • Chunks are prioritised by business value • Each chunk is called a Release • Typically, one Release corresponds to one business process • Knowing how we’re doing for the process, is the goal of delivering the Release © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 8
- 9. EDM® is end-to-end complete © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 9 Release Strategy Release n Plan Steering Group Review, Assess, Prioritise, Approve Iterative Development Release n Assessment Initiation (6 Steps) Executive Executive creates Steering Group Is there a business case for a business intelligence programme? If so, then create a Release Strategy and put the governance in place
- 10. Major Components Reporting/ KPI/ dashboard development Project Management Infrastructure Planning Business Needs and Analytic Themes Project Planning Governance Prioritisation Workshop Release Strategy Planning the Workstreams Infrastructure Planning Fix the order Release n Business Requirements Definition - what does thebusiness need? Technical Analysis Verify the data is available Define/ sketch/ prototype the business view of the information Define/ sketch/ prototype the business view of the information Validate that theproposed information willaddress thebusiness need Knowledge Transfer as required / agreed Define/ sketch/ prototype the business view of the information Analysis/ design/ build Dimensional model in SQLServer and Analysis Services Get a static copy of the necessary source data and build scaffolding to get it into the data warehouse Define/ sketch/ prototype the business view of the information Define/ sketch/ prototype the business view of the information Validate that theproposed information willaddress thebusiness need Define/ sketch/ prototype the business view of the information Analysis/ design/ build dimensional model in SQLServer and Analysis Services Get a static copy of the necessary source data and build scaffolding to get it into the data warehouse Iterative development hand-in-hand with the business Define/ sketch/ prototype the business view of the information Refinement of dimensional model in the physical database and hypercube data warehouse Formal Extract, Transport, Transform, and Load process using Integration Services Release n Implementation - Quality Assurance - User Acceptance Testing Infrastructure Build © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 10
- 11. Layered Architecture © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 11 Technology (Specific Product) Technology (Hardware, Networks, Infrastructure) Application (Systems, Components, Services) Data (Business Entities, Databases, Schemas) Information System (Data and Application) Business (Strategy, Priorities, Organisation)
- 12. Technology(specific product layer) © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 12 Extract, Transport, Transform, Load (ETTL) SQL Server Integration Services (SSIS) SQL Server Agent SQL Server Reporting Services (SSRS) Relational Database Relational Database & T-SQL Hypercube SQL Server Analysis Services (SSAS) Data Warehouse dimensional modelling physical build MDX KPIs Windows (e.g. authentication, Kerberos, Active Directory) SharePoint PerformancePoint Services for SharePoint Dashboard Designer PowerPivot Services for SharePoint SharePoint Designer Excel Services for SharePoint Total Solution Architecture (Business, System, Technical, and Product Architectures) Methodology and Governance Infrastructure Design and Build – SQL Server and SharePoint Install and Administer Programme Management PowerView for Cubes
- 13. Organisation and Staffing © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 13 Architecture Warehouse Development User Liaison Help Desk Infrastructure Support Reports Development Acceptance Test
- 14. Summary • EDM® is a methodology dedicated to BI • The principles of EDM® are – Evolution – Iteration – Collaboration – Incrementalism • EDM® delivers functionality in Releases • Why use EDM®? It works . . . a proven track record © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 14
- 15. Discussion © Redwing Business Intelligence Ltd 2002 - 2015 Methodology Slide 15 Donna Kelly donna@redwing-bi.com 0(781) 380-0181 www.redwing-bi.com
Editor's Notes
- 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 <click> Agile? 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.
- Examples: Alberta Government (several departments) Texaco Greater Manchester West (Mental Health Trust) We Buy Any Car Queen Elizabeth Hospital (Acute Health Care) Cardiff University London Commissioning Support Service (Primary Health Care)