This article is inspired by Udi’s post Non-functional Architectural Woes.
“This is how the business has been done for decades and will continue to be done for decades more” (Udi Dahan 2010)
As we build enterprise systems we are confronted with continuous change in the business requirements while the business as a whole remains the same as time goes by.
In a previous post i was investigating the possibility to indentify and cover the entire scope of the project using fractal theory. Based on the fact that scope of a project is discovered as we and are constructing the system, a method for uniformly (in terms of distribution) discovery of new parts of project scope would be appreciated.
One might notice that business objectives resembles to its business area, but are also somehow particular. The more you add businesses objectives together the more they look closer to the whole industry pattern. The more you dive into one’s business speciffic objectives, the more you find differences from the industry though keeping an resemblance to the whole. Makes me think again to fractal theory. The attached movie shows how a mathematical figure (the Mandelbrot set) is zoomed in and shows us details about it’s composition and resemblances of the initial picture.
As Udi says, and I kind of agree, the architectural pillars we should be interested in discovering while building an application should be close related to the functional requirements, more specifically business objectives. Decomposing the business objectives into smaller objectives (specific to the particular business and not the the whole) is quite hard.
It is not hard to decompose business objective into smaller ones because we don’t know how, it is hard because we have no clear knowledge on how to identify the real valuable objectives and to cover all of them. We should seek the method for covering all, the method for identifying the processes valuable, all-in-one the method (the fractal function as one might say). And if this method is applied over and over it might guarantee that we are able to find the all the most valuable objectives which if implemented might lead us to a stable business architecture.
You might say that agile methods cover this by iterating and clarifying objectives as the software evolves, whereas Waterfall methods rely on well documented living documents. Both strive to complete the business objectives.
One method, which I can guarantee to work if applied over and over, is to read and comment what other great guys have to say about things you are trying to discover, to be inspired by them and to constantly learn about the targeted business domain.
Subscribe