When performing process 1 - Develop an overall model - it is advised (..mandated?! :o) to model the underlying domain, bounded by a scope, where 'requirements are a depth check or a validity check of the shape within the scope'. I want to check some of the assumptions about this activity and question the thinking when hit by BPR.
With respect to say, automating an existing process (for example, Jo's Garage wants to replace its paper based process with an automated one), this concept of modelling the domain is quite powerful. If you analysed this process with a structured method (e.g. Data Flow Diagrams - or DFD's), you would see the same shape in the logical DFD. The integrity of the logical flow of data stays relatively intact before and after the new system is delivered. You would find the physical flow of data reduces dramtically on the introduction of automation. Cool. Once this domain is modelled, we should be able to easily produce requirements documents (which most beaurocratic companies demand) using modelling notes, the feature list, contractual/non functional details etc. This shape of project is probably more medium to low risk.
Where I think the challenge lies (not just with FDD, but with all methods), is in Business Process Reegnineering (BPR). What this basically involves is not just automation, but obliteration; of a business process, whether currently automated or paper based. From my limited experience this has come up often enough to be concerned, where there is an existing business process that could be more optimal (for example, changing from a bricks-and-mortar presence to a clicks-and-mortar presence, sort of like Dell). Using the DFD example above, not only would we see change in the physical flow of data, but also in the logical flow. This also gives rise to extremely high risk, as now there are:
- no domain experts
- no true existing material for developers to leverage
- a vast amount of speculation of what the underlying domain is.
The most important item I feel, in that list is 3. Without the business experts knowing how the underlying business will operate, this makes modelling the domain as brittle as building a domain model from ad-hoc functional requirements for whatever todays problem is.
Should there be a precursor activity to modelling the domain, if the underlying domain is sufficiently questionable? What is this activity? How do we know that this domain is stable enough to be modelled if it hasnt been "exercised"?
I was thinking that a business model for the business would make sense, but that does not really answer the final question listed above. How have other people, whether in or not in the fdd realm, handled this? Are you to accept that the liklihood of a project failure or requirements churn post implementation are high?
All very facinating.. just very costly :?
The problem lies in the domain anyway!
If you don't know what to build the problem of modeling the domain is irrelevant to the success and organization of the project. One needs to to tackcle first the problem of not knowing what to build. What I mean by this is that there is a problem layer above of the the one of building a software solution to automate a business process.
Business process re-engeneering should be out of the scope of the problem of building a software system. In fact it requires people with different skills and background. But the technical people can help. for that matter we can use artifacts such as prototypes that can help to understand and test the effectiveness of some business process that was re-engeneered. It is common to use the reengeneered processes in small teams, test its effectiveness and gradually enforce a a large scale adoption.
As for domain modeling, it a good approach to express and understand how the process is being engeneered, and challenge the underlying assumptions. In my own experience, is that yes you can't jump on in to modeling the domain, you need the output of work that should be done mostly previously. In other words keep the cost/effort of this work out of the software development project (separate cost centers).
Anyway, if Vision its important for any project, for BPR is of upmost importance. Without it the project dies, hopefully fast :)
Best regards,
Nuno Lopes
Hi Nuno, Yes! This is exac
Hi Nuno,
Yes! This is exactly what I would expect to see happen. Somone outside of technology (or with knowledge of, maybe a big 4.5 company) would help a business perform BPR.
You say it is a good approach for technical people is to develop artifacts and prototypes of a a process currently being transformed. Could you maybe give me an example? I can't really think of how we as technology can help so much, other than to give insight into technical feasibility (is this what you mean?).
Anyway I agree with you solidly on this issue :)
thanks for your insight!
No that is not what I mean.
Althought most projects that I have been involved requirements are pretty much stable (wether on paper or on the head of the business experts), in cases of full business process reegenering , tackling multiple business units, jumping directely to domain modeling works.
Now when it is not the case (common within the scope of full fledge business process reengenering), one should demand that requirements documentation include the shapes of the intended business processes. This can be done with DFD or another language that allows one to define the workflow. It doesn't matter so much that the data is fully specified (that can be done during domain modeling and design phases on FDD). Usually business process reengeneering documentation include this, plus the expected gains in productivity and quality enhancement).
Usually when one developes a new software system it is often the case that provides opportunities for process enhancement was not observed when during requirements gathering phase. In order to spot this before a full fledge system development one can use prototypes.
Requirements gathering is a form of analysis, but in order to avoid analysis paralisis IMHO one can start building the protypes before all requirements are gathered (all business processes are analysed by the business experts) and agree that full system building will start at a specified data no mater what.
IMHO, there is a significant difference beween business process reengeering and the the opportunities for process improvement that a technical system uncouvers when automating a process otherwise manual or less efective. The first is usually disruptive (culture wide) while the second is part of on going process improvement (process improvements requires that a process is in place already and simply needs to be automated or fine tunned). I have taken you question within the scope of the first rather then the second.
Best regards,
Nuno Lopes
Infinite recursion
I don't understand that last sentence and I strongly disagree that the shape produced by a DFD will look the same as a (good) object model (if that is an implication you are making).
Again, I just don't follow what this logical and physical DFD stuff has to do with the object model in FDD.
Also, I dont accept at all that you've established why "this shape of project" (sic) is more medium to low risk.
I'm confused. I don't understand the differences you assume. The first case is automating an existing process without any change at all (a rare event in my experience as automation presents improvement opportunities). The second case is optimising or enhancing an existing process. I don't accept that this always means the second case is high risk and I don't believe you've made that case. If the three issues you listed are the case then undoubtedly you are in trouble and no process will help you solve a problem that you cannot even bound or define. Again, I don't see the leap though from the "optimise a process" case too those three issues being the case.
Pushing the problem into a pre-cursor black box solves nothing.
So, how to solve the problem of object modeling when there are no domain experts, no existing material for developers to leverage and vast amounts of speculation of what the underlying domain is. Your answer is to do business modeling first. Terrific. And how do you do that with no domain (business) experts, no existing material to leverage and vast amounts of speculation about what the domain (the business) is? (and I'm ignoring what a business model is vs a domain model)
Perhaps a pre-cursor activity to business modeling might be the answer? (tongue firmly in cheek)
If you have no domain/business experts. No existing material to leverage. And vast amounts of speculation about what the business is, you shouldn't be implementing anything. What is it you are going to implement? (rhetorical)
Got domain?
In more detail this should say:
If you analysed a business process pre automation with logical DFD's, you would expect to see a similar output after the process has been automated. That is the logical flow of information is still pretty much the same, just the physical flow has mostly changed.
...And I agree entirely that a DFD will not look the same or as good as an object model. :)
The DFD stuff doesn't have anything to do with the object model! I'm just trying to look at object modelling from two key perspectives: 1. pure automation of business processes and 2. bpr of business processes.
DFD's do not provide you with the rich knowledge transfer/analysis, or the stability for developers to code from. Forgetting FDD for the minute, the logical and physical flow of data can still be interesting to analyse. It is interesting to see that in the cases of pure automation (1), building an object model is a perfect fit as the logical flow of data, (to the client) is basically the same before and after a system is built. To be more specific, e.g. Currently, Jo has handles repair work by issuing a quote to a customer, then filling the repair report and creating the invoice, cash reciept etc. After the new system has been built, the logical process is still the same. He still issues a quote, files repair reports and creates invoices, cash reciepts etc. The physical flow of data will have changed (he now uses the computer rather than paper and filing cabinets), but the thats what automation is all about.
In the cases of bpr, I'm not sufficently convinced that any method can insulate itself from fundamental changes to the domain (Jo's business advisor says he can save money if he changes the way he does parts acquisition from phone calls and manual paperwork to automation thorugh an existing software product for example). If you ask Jo how his business does parts acquisistion, he will tell you how he does it currently, not how his new business process will work. This is not intentions of the new system, but his business process.
With regards to the risk statement, it would seem that if you are automating a business process, it would be less risky then automating a new "unused" business process.
My first case assumes change, just not as fundamental. I agree that automation always presents opportunies for improvement in one place or another, but these are more in tune with the incremental quality improvement as you would encounter in total quality management I would have thought. And I think you are maybe seeing where I am coming from on the issues of lack of clarity of business process to be modelled, which would hopefully cause no project to begin until it is defined. I arrive at this from looking at how much change occurs in the logical flow of information before and after a system is built (the old-er- method of systems development). If there is small to medium change in this logical flow, I would envisige a higher degree of success of a project. Where this is high, I would expect to see stalling or rework /retrofitting of requirements that were not done properly due to the fundamental change of business process/change in the domain to be modelled. Is this a fair assumption?
I think I just realised what that was about! haha
Yeah it's rhetorical but I need to add something. What if your client needs to change for competitive advantage? A change to an unfamilar way of working needs to be defined, and yet us technology guys say "yes we can do it! :D") Would it be fair to say that before Luke goes off and models the domain, Luke makes sure there is a domain to model? Do we as technology guys help facilitate this? Or is this for someone that truely knows business modelling?
Just the scope part (for now)
I'm answering just the very last part of your comment for now. The rest contains about 6 other issues that are worthy of discussion too (such as the disconnect between process automation, bpr and the domain) but this is all I've time to answer right now.
You still haven't defined what business modeling is so I can't tell you if I think that would help or not.
If your client needs to change for competitive advantage, that's the strategic business change they want (although usually they will have defined this in more detail), then they will also have identified the set of business outcomes that collectively achieve that strategic business change.
The business doesn't (shouldn't) come to IT and say we need to change for competitive advantage but we don't know how, and ITs response is to say well let's build a domain model of it. There is no it to scope the model.
You say there is no domain - there's always a domain - what you don't have is that scope bounding box I talked about in the workshop.
Now don't misunderstand me. I'm not saying that IT can't help the business achieve competitive advantage or that it can't put forward IT solutions that bring about competitive advantage. But it has to be business driven.
How is competitive advantage even defined in this instance? Is it the ability to increase market share, the ability to service faster than your competitors, or at lower cost, or with greater (business) customer perceived value, or...?
This alignment of work to the business is key. I like to use Lewis' results hierarchy for this (and some of the below is text from him).
At the top of the hierarchy is the program. A program is a coordinated set of actions chartered to achieve a strategic business change - such as lower cost, faster service, time to market, etc.
A strategic business change doesn't become an operational program until you've established a concrete set of business outcomes which, taken together, achieve the strategic business change that is the goal of the program. A business outcome is a well-defined change evident to staff, customers, suppliers, distribution channels, or some combination thereof.
Moving from paper transactions to web services for purchase orders, invoices and other supply-chain documents is a business outcome. So is the implementation of a new customer knowledge-base, so long as the "implementation" includes processes for keeping the customer knowledge-base current and accurate.
After you've identified a strategic program, your next step is determining what business outcomes will be needed to achieve the goals of that program so you can establish an initiative to acheive each one. Initiatives consist of several coordinated projects - the third level of the results hierarchy.
A project is a collection of executable tasks that deliver tangible results, like a recommendation for a system vendor, an installed, customised, integrated system, or a new process design. Projects produce "deliverables" - the name for the tangible results of a project.
Finally, projects are broken up into tasks and subtasks that lead to the achievement of milestones. A milestone is simply the occurence of a recognisable event, You don't plan milestones when planning a program - that's the job of a project manager.
That's the alignment structure I like to use and I often recommend.
FDD's Develop an Overall Model process is an early major task inside of a single project...
Your question is "we don't even know what the strategic business change is and how does FDD's modeling help." That's easy to answer - it doesn't help.
Jeff
I don't think there is an Infinite Recursion
It might be an infinite recursion in theory but not in practice IMHO.
What I want to tackle when I advise to establish the shape of business processes prior to domain modeling (that is in requirements gathering, an issue that is not tackled by FDD as it assumes that most requirements are in place) is precisely the fact then in case of business processes reengenerring is not the same as process improvement. Requirements gathering within the scope of how the business should be run should be done by business savvy people not CP's or even System Analysts.
There is an infinite recursion indeed if business people eternally don't know what they want. But even within the scope of BPR I have never witness this. What I witness is that it takes more time for them to greatly improve a process to the point that the finished one only slightly resembles an existing one or creating a new process then to slightly improve an existing one.
For instance, take eBanking for instance. Online banking is similar to traditional banking in theory, but in practice it requires an entirely different approach in terms of customer service processes. Some banks allow one to open accounts online others don't. The reason why is that in the later the internal processes are not in place becouse the bank does not know even in abstract terms how to deal with it internally and externally. I honestly doupt the domain modeling would help this bank.
Nuno Lopes
Clarifying
Hi Nuno,
I meant that in terms of the OPs thinking that a preceeding step that is undefined somehow fixes the problem. That thinking can then be applied to to newly added step, resulting in another preceeding step and so on. The thinking not the practice.
No, your only major entry criteria for the modeling is to be able to identify that subset of the domain bounded by the scope of this particular system/project. It is that scope bounding box that must be reasonably defined - otherwise you have nothing to faciliate against during the modeling and you will end up modeling the world.
There certainly are implications if that's all you have and there's been no work on detailed requirements - such as the gap documents you will need to produce after the modeling completes - but it is not an entry criteria (or FDD assumption) that most requirements are in place.
Jeff
Thank you for clarifing
Hi Jeff,
"I meant that in terms of the OPs thinking that a preceeding step that is undefined somehow fixes the problem."
Yes not this is not the same as a preceeding step that is well defined (or the scope is well bounded and the purpose well defined). Anyway I was not thinking in terms of preceeding step regarding domain modeling but a business oriented exercise by itself. That is, irrespective to the fact if the process will be automated or not. In fact requirements are the outcome of this exercice.
This seams logical, but I've been in a project were deep business issues such as process reengeneering were left to be exercised during system development (and project failed). The project went bad to the point were the PM in order to meet deliverables had to make business assumptions (or decisions) as the business people were unable to decide. The diagnostic was that analysis was not well done ence the project failure. So analysts were to blame? But this analysts were mainly people with IT backfround with good experience in system analysis, prepared to deal with business facts not conjectures and much less with business speculation. Inspite of all problems the project reach its end (late and expensive). The all system was taken offline 4 months when business people found out that the all business was fundamentally illegal in Portugal :)
Nuno Lopes
PS: This happened in a top IT consultancy company in Portugal.
Using It to get into a new business?
Nuno, correct me if I am wrong but it sounds like what you are describing is using an IT system to get into a new market or develope a new product, that the business people did not properly understand or had not thought through. I have seen this and the resulting shifting business decisions onto IT people. Its a recipe for disaster.
I repeat what I just said. If your Domain model (within a fixed scope) is not stable then something is badly wrong. I am not talking about elaborating details, I am talking about what Jeff calls 'model shape'. If you cannot fix the domain model, i.e. make it stable, don't proceed.
phil b
Yes you are correct!
Yes you are correct phil, but the business environment constraint does not necessarly need to be within the realm of developing an new product or get into a new market. IMHOm, an enterprise wide objective like "change from bricks-and-mortar presence to a clicks-and-mortar presence" - is enough to steam up these issues, especially when the company have significant in-house business experience in running an online business as it happens with most businesses. Symptomatic of this is when we witnesses business people asking IT analysts with little business background for suggestions regarding optimization of internal processes. As most companies in the world are not yet online, this happens quite often.
As we know, sometimes a project needs to fail in order to get the next one right, I just don't want to be the manager this project ence my initial observation in this thread, unless action is taken to reach a compromise regqarding the "real problems" of the company within the scope of the objectives.
Nuno Lopes
PS: Inspite of these problems the project still needs to be a success and there is little excuse for it not be in terms of delivery.
Correction:
"IMHO, an enterprise wide objective like "change from bricks-and-mortar presence to a clicks-and-mortar presence" - is enough to steam up these issues, especially when the company does not/ have significant in-house business experience in running an online business as it happens with most businesses.
data flow and domain models
Hi Mangrish
I should probably read this thread in more detail than I have but a couple of observations which are really about the premises we are operating under.
1. In an (modern) information system data doesn't 'flow'. Data only flows, in the sense of physically moving, in manual systems and obsolete batch systems. DFDs are a useful technique for analyzing these systems. It is not a useful tool for designing an information system. A DFD is most definitely not a Domain model.
2. DFDs confused two things that you need to separate. One is the process and the other is the physical distribution of the process. This is what I understand as the distinction between logical and physical. Both can change with introduction (design) of an info system but the physical tends to change much more (in my experience changes to the logical process are very rare). To use your example of a chnageover to a clicksnmortar operation there is a core process that will change little if at all but its physical distribution may change radically. E.g. rather than recieving an order through the mail it comes through a website. You still recieve an order that doesn't change. Most importantly that core process has an existence independant of a particular physical implemntation at a particular location, e.g. the website (or call centre) could be anywhere.
3. Domain models are very stable becuase they represent what the business does - its core process, not how its information systems work. The concept of scope is very important, because scope represents the boundary of your system. Within the boundary of the system there are two things. One is a representation of the business core process and the other is a record of things that have happened to the business within the scope of the system (i.e. the scope of the core process). If your system is concerned with orders then it contains a record (history) of orders recieved, built, shipped, returned, etc.
4. Business processes do change, but in my experience its becuase of business changes which have nothing to do (or only incidentally) to do with IT systems. I'm not talking about eliminating redundant data moving steps like going to the mail room to collect the mail. I'm talking about changes to how a business achieves whatever it does. The example that springs to mind is a college introducing a remote-learning way of obtaining a degree.
In summary, if your domain model changes within a fixed scope becuase of any IT or implementation decisions you make, then its a bad domain model.
I'll leave requirements alone because its a slippery concept, except to say I have told a number a number of clients 'Don't tell me your requirements. Tell me what you do (i.e. the business does).' Becuase I am modelling what the business does and not what the information system does or how the business physically distributes processes.
phil b
DFDs and the Domain model
Mangrish, I read your later posts and you seem to have a good grasp of separating the stable core business process from the unstable implementation. You could use DFDs to produce elements of a Domain model (note to Jeff: It would be a stack of pinks). Its something I might try if someone else had produced the DFDs. But I would not recommend it as a route to a Domain model. DFDs as a process sucks you into the details of the current implementation, what I used to call the 'system topology' i.e. how the core business process is distributed and implemented across the business.
phil b
support for reengineering
While no FDD (or other development methodolgies) can (I mean must not) invent into the business domain, they can support it. My tipp/idea is that this support must deal with "explorer style" development - here you can quickly build/deploy new things, can easily capture/evaluate feedbacks, and can revert/step-back if neccessarry. This style of programing is very similar to (mabe a clone of) the agile-style programming (refactoring, integration, test-automation, etc.).
In respect with FDD... For me FDD seems to best support "build-style development" (forward engineering) here it gives excellent support. Meanwhile it gives just avarage support for "evolutive development" (reengineering). This may be because FDD emphasises a top-down approach (puts focus on the business perspective). Meanwhile the N+1 development inherently relies on a bottom-up approach - though this may change in time (if MDA or kinda breaks through).
Definition
I think we'd have to carefully define some of your terms. But I mostly agree with the sentiment you're expressing in paragraph 1 as regards to "explorer style" development. (note: I don't agree that all Agile development = explorer style).
You lost my agreement in paragraph 2 though when you used the term reengineering. I suspect, with definition, we'd may end up agreeing.
My interpretation of reengineering applies to most of the projects that we do. There's not much greenfield stuff these days. Also, and those that have been on my workshops would know how much I bang on N+1. FDD fully supports and enables N+1 (it's close to a religious topic with me).
So, if you stick with "explorer style", then in sentiment at least I agree.
Having said that though, can it work for this style? Of course. Does it work for N+1? ABSOLUTELY.
Even when two people, one domain expert, one coder are working informally say as Paul and I do often there's a big difference in results depending on the surrounding practices. e.g. just one person and a coder, doing things informally, when the effort is made even to just enumerate features that describe the work to be done there is a big difference in results. Now there is clear visbility into what is done, what isn't what progress has been made, what it is we have, what's left to do, etc. Left to "just do it" it rarely "just gets done..." :-)
model the domain... model the business
The business and process models should be assessed and where necessary new ones should be developed. This can be be done in much the same way the application PD is developed.
1. Develop the overall business model representing the organisation structure, processes, functions. Develop end-to-end process diagrams and map to organisation entities (businesses, departments, user classes). Identify what processes your new application will eliminate or what process you want to improve/eliminate (e.g. manual tasks or data entry through use of online forms).
2. Fill in detail - detail processes within a department, activities performed by user classes, etc.. Identify the capabilities (analogous to features in FDD) that are required (e.g. Outbound Call Capability, Mail scanning, fax gateway, etc.). This provides input into the application domain modelling.
3. Build by Capability - and if you did a good job this is where you start the application domain modelling. To ensure a good, flexible, responsive loosely coupled enterprise architecture try making sure business capabilities are defined such that they have a very clear process accountability. This will ensure minimum fine grained interactions with other business capabilities. A good test is if the data flowing between business capabilities can be more or less represented by a business document (purchase order, invoice, report, etc.). The UN/CEFACT modelling methodology has good guidelines for B2B design - try following these.
And I am not sure what we do for step 4 and 5...
You may need a slightly different group of individuals to perform this activity though.