Top 10 SOA Pitfalls: #5 - Big Design Up Front
Like the Not Invented Here syndrome we discussed earlier, Big Design Up Front (BDUF) is something not only witnessed within the realm of SOA. However, where the NIH syndrome is generally accepted to be a bad thing, things are not that simple when it comes to BDUF.
The term BDUF refers to the practice of ensuring a design is complete before any implementation is done. BUDF is traditionally associated with the waterfall model of software development. The advantage of this practice would be that most problems can be discovered and solved in the requirements or design phase where they are easier to solve. However, proponents of agile software development argue that IT requirements are bound to change during the development cycle, so BDUF (or Big Modeling Up Front) will only make it harder to adapt to change.
This is just a short summary of all the issues surrounding BDUF. You can find more arguments for and against by following the links in the previous paragraph. Let's zoom in on what it means for a SOA. First the obvious: SOA projects tend to be large projects. One of the reasons for this is that organizations hope SOA is the silver bullet that will solve all their complexity issues (as discussed int the previous post) and therefore they will not only start a SOA project, but will actually start a SOA program. That SOA program will consist of many projects (sound familiar so far? ;-)) that are each tasked with solving a particular subproblem such as "business requirements", "process design", "organizational implementation", "technical architecture", "development", etc.
Now herein lies the rub; the teams that are tasked with doing the business requirements, the process design and the technical architecture, will do just that. Their focus will be on getting the requirements, the design and the architecture just right while the development team is only just starting up. Not being hampered by actually having to implement the stuff they come up with, these teams just keep adding and adding to their designs, while the development team is having a hard time to catch up. When do they catch up, these teams may even be finished and disbanded! We've seen this happen when no one keeps an eye on the big picture. :-(
Not withstanding all the obvious disadvantages to BDUF (large documents that are hardly adaptable to change), BDUF tends to have another specific effect in a SOA. It tends to lead to a top down design style, which can cause services of incorrect granualarity.
One of the scenarios that can lead to this is that the process designers focus upon getting the high level (business-wide) process right first, then move down to the department level processes and finally they get to the services at the bottom of the hierarchy (see picture on the right). The end result is that you can end with a service A1 with a signature like Address getCustomerAddress(String customerName) and a service C3 with a signature like String getCustomerStreet(int customerId). They've been designed and specced separately and it will take some effort discovering these similar services and replacing them with something that is more reuseable. One way to prevent this is by keeping a service registry that designed can use to find the services they need. This need not be a UDDI directory, just something that the implementors can employ.
To conclude, we propose introducing SOA in an Agile manner instead of the "big bang" approach usually employed. Agile and SOA are, respectively, a methodology and an architecture style that have been introduced to make organization more responsive to change. But strangely enough, SOA tends to encourage some decidedly non-Agile practice such as BDUF and "functional" teams. Agile and SOA can be friends, but done wrong they are foes. It goes beyond the scope of this blog post to go into more detail, so we will come back to Agile & SOA at a later date!
In the next article in this series, Gero Vermaas will continue with pitfall #4.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)