Hi,
I currently working as an Architect in a large scale, quite complex, systems integration project involving integrating COTS (ERP, SCM) with in-house developed components (Data Warehouse, Enterprise Service Bus (Middleware), Integration Adaptors/Wrappers) and interfaces to legacy and customer / supplier systems.
We have major issues with requirements. The solution is supporting a brand new area of business the company has never been in before. Therefore, end users and managers in the business cannot provide us with any level of detailed requirements, only the high level business need. To compensate a good proportion of the team members have extensive experience in the domain. We already have an initial release of the solution live and successful. The current release we're working on is sustantially expanding the "solution footprint". We also have the issue of iterating requirements against COTS capabilities which, in turn, causes flux in design requirements for the middleware. For example the ERP consultant implements a particular use of an ERP object (e.g. process, states etc), the development team begin to map those states into events on the middleware for integration with other components, then a subsequent iteration with the business changes elements of the ERP model causing a number of design assumptions in the middleware to become invalid. We are protecting ourselves against this to a certain extent through the design of the middleware - extensive use of XML and XSLT in an open standards J2EE / JMS framework.
We currently using a Use Case driven approach to requirements management and documenting design using UML. Although we've taken a number of good practices from RUP, we're not trying to implement it prescriptively. Having extensive experience of RUP and Objectory I believe it's too heavyweight for the programme and the "culture" of the team.
My view is that a use case driven approach, due to factors above, has not been as sucessfuly as I've used on previous projects. Mainly due to the very high instability in requirements all through the life cycle. In some cases the business has not been able to articulate the "real" requirement until the system has been live of a number of months!
I'm look to move our process on and I am interested in the concept of FDD. As a software engineer for over 17 years, it strikes me as intuitive and natural.
Anyone any views on adopting principles of FDD into such a programme environment?
Yours
angordon
FDD can be applied
Our first experience with FDD on a large scale project included some of the same issues you have described in your post including integration of multiple systems and a problem domain where the details were not well understood. The FDD methodology proved very successful, resulting in our adopting it as the standard methodology for subsequent projects (with a couple of non-FDD projects thrown in to further validate our experience with FDD -- in all cases the projects managed with FDD resulted in much better tracking, accuracy and ability to report real project status/progress).
Key factors that contributed to the success of the FDD approach were the buy-in from the development team, having the team participate closely in defining the features lists (overall and detailed), and close tracking of the project by the Project Manager. Initially we would post project status twice weekly, but as we gained experience and started approaching the end of the project, we were updating and posting project status daily. Being able to do this without requiring significant effort from the developers and the effect of visual project performance (against other teams/areas) had a significant positive impact on the project.
We were under considerable time pressure since we had a fixed launch date and partially undefined and changing requirements (which resulted in relatively frequent changes to the features list, particularly at the detailed design by feature/build by feature level), however our ability to accurately track project progress allowed us to make maximum use of team and individual capabilities and to focus on avoiding issues that put any area in danger of falling behind.
FDD isn't the elusive silver bullet; but in our experience it provides a lightweight, intuitive, flexible, and efficient process that allows teams and individuals to focus on building working software instead of satisfying process requirements. If you think your team is open to the concept, is willing and able to participate in developing the feature lists, and you have a project manager who believes in the approach and is willing to commit to making it successful, I believe you will find FDD an effective methodology.
Using FDD on a Business Intelligence project
The effectiveness of FDD stems from the change in perspective that it brings. Developers, managers and business people start to think in terms of features, rather than in terms of their own comfortable, familiar artefacts.
For example, a developer typically thinks about technical artefacts. These may be at the design level (layered architecture, SOA, patterns, class models) or at the implementation level (security subsystem, logging, exception handling, methods, unit tests, refactoring). Enter FDD, and suddenly the developer is thinking 'customer valued features'. This altered perspective has a profound impact on developer behaviour since the measure of progress becomes 'feature completion' rather than artefact production.
Similarly, the project manager has a customer-valued WBS (the feature list) to focus upon rather than an activity-based WBS with myriad dependencies.
The business suddenly sees people working and talking in their language. This engages and energises the business like nothing else can.
So, I'm sold on FDD and have applied it on bespoke application development. However, I am now on a BI project. This sort of endeavour really highlights the 'iceberg' issue we face when trying to surface customer value. That is, to surface a small thing of value (a BI report), there is a tremendous amount of infrastructure that has to be built under the surface (ie the data warehouse).
What we'll try and do is attach customer value to some of these 'under the surface' activities (eg data profiling, ETL, data mart creation, cube production). This may get tricky because the customer really sees value in the surfaced reports, rather than the mechanics of sourcing them. I guess this is similar to customers often having a GUI focus, rather than a 'back-end' business rule focus.
Because the BI is surfaced through a portal, there is an opportunity to give high visibility to the features and their status. We hope to 'portletise' the standard FDD reports and expose them through the BI portal in a 'whats new' section.
The main benefit of FDD that I have found is the traction it gives a project. Often we find ourselves locked in technical debates over products or architecture. I use the analogy of a team of chefs out the back, arguing over the colour of tiles for a kitchen redecoration, while the punters starve out front in the restaurant. With FDD, it's a case of saying to the kitchen team "forget the decor, just get some pots and pans and start cooking!". FDD is about frequent, tangible, working results which leads to satisfied diners and repeat business!
FDD and Software Packages (aka COTS)
I haven't looked at the FDD site in awhile so first, I wish to apologize for making a belated entry on this discussion thread. It may be a tad late to assist the original requestor, but will perhaps be more valuable to those that follow in his or her footsteps.
I would concur that there's a basic chasm -- a divide or disconnect between the domain experts and the software engineers that must be crossed -- that is in translating a loosely described business need into a more formal software requirement -- or ultimately, into a specific software feature. Let me describe for you my view on how FDD can help you cross this divide.
I am an ardent supporter of using FDD in the packaged software environment. In fact, my first exposure to FDD concepts came about in a project where a series of software package acquisitions were going to be melded together into a single product (the best of the best features so to speak) and FDD seemed like a great way to arrive at the user valued features (in this case the features were ranked by both customers and product managers as to their business value).
The features list is an excellent way of cataloging and ranking the business value of your requirements. The features list then becomes the 'software shopping list' used to compare -- to determine the degree of completeness in satisfying each business valued need or feature -- from amongst various packages.
Besides adopting a feature driven approach to writing package specifications, I highly recommend a look at and adoption of the simplest and most elegant business application software model I've found. It's from Chapter One of the book Java Design (2ed) by Peter Coad, Mark Mayfield and Jon Kern. First, let me say that you don't need to use Java to benefit from this model. This model is a great way of generalizing any form of business application software and with a little imagination (which I subsequently applied by 'stretching' this framework into more of a software package architectural model, which I describe in my own book, Maximizing Business Performance through Software Packages) is a good foundation for thinking about and describing the features a software package minimally needs to support any given business process.
In practice, I have found that use cases are indeed a bit cumbersome for specifications in software package work. Software people might embrace them, but business domain experts don't really understand them (at least not as well as they did traditional flow diagrams). Why is this so? I contend that what business domain experts think about are the process steps, the functional handoffs and the next step decision points, not the implementation of their requirements as an abstract, generic, technical model (aka the UML). Many find the use case narrative as a bit stuffy or too matter of fact as a functional specification of a business process flow. Finally, if you're putting in the amount of effort at writing specifications which use cases tend to require, for what are now largely 'commoditized' application areas in software packages, it is perhaps wasted effort. Instead, focus on the show stopper areas of software functionality needed to support your unique business model and 'use case' only these.
This of course leads to a discussion of my preferred method for detailing business processes in motion: the SIPOC (Supplier, Input, Process, Output, Customer) model, which is drawn from the Continuous Improvement/Quality Management literature. It's a narrative, step-by-step walkthrough of a business process (which of course uses software features along the way). I then use a tool called allCLEAR to draw a chart of the processing steps that can be used for business domain expert/process owner confirmation discussions, by simply copying and pasting my process steps into allCLEAR out of my SIPOC template (I created the SIPOC template I use here).
Use cases (I'm referring to use case narratives, not stick diagrams here) can however be applied successfully in several areas of software package work. One use is for the demonstration scripts of key business processes that are usually provided to software vendors for software demonstration purposes (I have a template for this) and another use is for conference room pilot testing scripts, which are then later used as training scripts. (By this time in a software selection or implementation you're ready for the matter of fact approach/structure that a use case narrative implies/instills).
Now, in a scenario where extensive customization of a software package is needed (including interfaces to other software packages, or custom and legacy applications, your customization strategy is first and foremost driven by the core software package. Customization must preserve and extend the look and feel of the core software. This typically means using the development tools available for a given software package (i.e. ABAP for SAP, PeopleTools for PeopleSoft).
Interfaces to and from any software package must conform to the data import/export specifications available in the core software package period. This must be done to protect the data model integrity of the package itself. Yet to allow for maintainability and further extensions in the future, the choice of XML as the transport mechanism for entering and exchanging foreign data between software applications is quite reasonable and highly desirable. However, if a package doesn't have XML, but uses EDI instead, you might need to transform and transport data as EDI transactions 'inside XML' -- this is the technical side (and there's lot of it), not the business domain side of the architecture (which usually gets all the attention) involved in software packages.
Getting your funding software owners to understand the business value of software architecture is a challenge all to itself. Service oriented, messaging based bus architectures are all the rage right now, but will business users value these architectural shifts enough to pay for them? (Noting that some industry analysts suggest these changeovers will cost 2-3 times the amount of the original software investments already made.) So often, what IT receives in the way of architecture is what the selected software package brings to the table -- no matter how good, bad or ugly that may be. Thus, today's highly customized software packages are destined to become tomorrow's legacy system challenges. SOA doesn't eliminate the problem but ultimately the coming remake of software packages around SOA might make interfacing and customization simpler, more acceptable and in the long run more cost effective.
Lastly, I am so adamant about the use of FDD concepts in the COTS area, that I have formalized it into a process that for lack of much imagination or creativity on my part, I'm calling Feature Driven Software Specification (FDSS as I call it). While a formal document describing FDSS is still a work in process (look for it to be available in early 2006) the concepts above form the nucleus of my work in this area and were loosely described in my previously mentioned book. I am also developing a software tool that will support the FDSS process. If there's anyone with additional interest in my FDSS work, please feel free to contact me at fdss 'at' tradewindsgroupinc.com.