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.

I had a discussion recently with a colleague about how to assure your project team to cover the entire scope of the project with usecases. The example was associated with a rectangle as the scope of the projectand some small rectangle, covering each other, and trying to cover the entire scope.

Although the problem of defining a use case is difficult,now I want to talk about how to cover entirely some area, not with shape, bu twith method.

Rectangle are simple, so are some projects. Most projects are difficult and their scope reveal to the team as time passes by and as more experience is acquired. As a parallel to geometrical figures we can imagine a project as being complex irregular geometry figure, which in order to becovered require different shapes, and rectangles are in most cases a bad choice.

Let’s introduce some theory: “A fractal is generally "arough or fragmented geometric shape that can be split into parts, each of whichis (at least approximately) a reduced-size copy of the whole”

In order to generate a fractal figure you have to have a starting figure and a method, and by applying the same method, over and over, you get the final figure. The more you work on, the more detailed the fractal figure gets.

Another interesting fact about fractal figures is that theycan have factionary dimension. It is well known that points have no dimension,lines are one dimension and the surface has 2 dimensions, space 3, and so on.

Fractals figure can face 1.5 dimensions, meaning that it ismore than a line, but not a surface. There are also fractal figures which have dimension two. This means that they can be assimilated to a surface, they can cover a surface. xample the Dragon Curve

You have a starting figure and a method. Apply the same method over and over and you will cover a surface, any figure.

Now, back to our problem, we must cover with use cases aproblem scope. We must find two things: the shape of the starting point, the method to be applied over and over, and not least the starting point.

Now, where should be good starting point ? Inside the shape given by all the actors of the system.

Conclusion: wisdom for the figure, and perseverance in applying the method will get you to cover the entire scope.