What do you mean by “real time” ?

Glad you liked it.

When working with other programmers, it’s often the case that they tend to think that it’s more important what specific tools you’re using, rather than how you use them and what you use them for. For example, someone once told me that it’s important to be *really* good with ReSharper, because it will help you build your designs effectively. I’m a RS ninja, and I categorically disagreed with him – that is, I told him why it neither helps nor hurts a design, and should *not* help or hurt design. It would be good to have tools to help design, but it’s still fundamentally a human problem, I think. Naturally, that same person said that it’s only if you’re using TypeMock that you can really design a real system.

Finally, I’ve found lately an MVVM craze that forgets the first piece of the pattern: the model. The models are trash, but they have these “elegant” view-models that make it easy to tie themselves in knots.

Sorry, this turned into a bit o’ the rant. Good post, Udi.

“At what point does accountability of the crazy req start?”

I do believe your horns are showing, Mr. Devil’s advocate

Are those requirements really that crazy? If we had developed the system differently and it were easy for us to implement those requirements, would they not be crazy then? Is it the business’ fault that they didn’t give us these requirements up-front?

OMG – are we going back to big requirements up-front to avoid these problems?

We’re going to find the right balance between all these things – hang in there

After reading your post and the comments above, I think that this quote can serve as a kind of summary of your position (please correct me if I’ve over-simplified):

“This particular rash of BPM products built their business on the fallacy that you could somehow build solutions directly from ‘problem-side abstractions’.”

Note that in my post, I didn’t say to build the solution DIRECTLY from the “problem-side abstractions”. I said that we need to capture certain *stable* elements of the problem domain and have them represented explicitly in the solution domain. At that point, we can continue with good solution domain practices and avoid many of the situations described in my post.

> Is it true that one business objective resembles to its business area, but is somehow particular ?

Business objectives can usually be sourced to a single stakeholder – someone who is measured a certain way by the organization around them. Our goal is to find them.

> Is it true the more you add businesses objectives together the more they look like the whole ?

Not exactly sure what you mean by this, but I’m feeling that the answer is no. We need to find which objectives go to different stakeholders, and then decouple their implementations in software.

> Is that why we can easily formalize business theory and hardly manage to formalize a running business ?

I don’t think that we can easily formalize business theory, but agree that there is difficulty in modeling (let alone formalizing) a running business. The larger the business, the more likely it’s undergoing some reorganization, merger, acquisition, entrance into a new market, exit from some other market, etc. The goal is to identify those elements and segregate their implementations from those parts which represent more stable parts of the business.

Hope that answers your questions.

I’m playing a bit of devils advocate here…

I detailed my ideas here http://www.dependnet.ro/blog/post/2010/01/17/Business-Objectives-as-key-architectural-pillars-doubled-by-fractal-inspiration.aspx

I think that’s fairly relevant to what you are attempting to achieve.

JJ-

>> but even the most skilled of us are in difficulty to well formalize
>> these concepts.
This comes from the fact that the current modelling paradigm is “OO” based and surprisingly does not integrate behavior. All models are reduced to elements with attributes and references to each other. “Behavior” is strangely left to be under the hood in the metadata interpreter or compiler. So you are left to describe “behavior-less” models (on the problem or solution side). This is wrong.

Shall we ever be able to represent business knowledge in a structured/programmable way or shall we always concentrate on the ability to change our software according to the always changing functional requirements.

We, as humans, are able to represent in our minds the concepts, the domain, we are able to expose parts of it to the outside world, but even the most skilled of us are in difficulty to well formalize these concepts.

Indeed business is done in the same way for decades, business as a whole. Some business objectives are the same and some are very particular. It is why extracting the architectural artifacts from the functional requirements is difficult.

Is it true that one business objective resembles to its business area, but is somehow particular ? Is it true the more you add businesses objectives together the more they look like the whole ? Is that why we can easily formalize business theory and hardly manage to formalize a running business ?

These were my questions. One could answer that the solution is related to fractal theory.

Looking forward to “more to come…”

I have developed a more elaborate response here: http://www.ebpml.org/blog/212.htm

JJ-

>> the only thing is that there aren’t any inherently stable
>> abstractions in the solution domain (as we’ve had the chance to
>> witness).

That’s because you rely on vendors for these abstractions. I think it is time to develop a stable (Architecture independent – not just technology independent) set of Solution Abstractions.

I have described how to go about that in a generic way here: http://www.infoq.com/articles/mop

The problem with traditional approaches, UML, EMF or now SSM is that somehow they are anchored in OO, i.e the concept of “Class” is at the center of the M3 layer. I was hoping SSM would change that, but they did not. The irony and tragedy is that none of the “solution abstraction” can be efficiently described with an OO foundation.

So if you go int the problem space and try to create abstractions there, you’ll run into the exact same problem because all models are built on sand, i.e. OO.

It sounds like we’re very much in agreement.

I’d say that ’shortening the time for an order to be fulfilled’ is an ongoing business objective that is the spirit behind many specific software requirements that we may get.

The question that I intend to address in my next post is how we take this business objectives (requirements) and capture them in our software architecture.

Thanks for your comments.

The requirement ‘As a supplier, when I log-in, I want to see on my home page my most recent purchase orders,..’ is a software requirement. It’s something the sofware must do.

The business requirement is something like ‘To shorten the time for an order to be fulfilled.’ Or business objective.

The input to architecture decisions are the business requirements – not the software requirements, which come later once you’ve determined what the solution is.

Too often we just don’t do business requirements. Or we take software requirements from users and call them business requirements because they cme from the business. That’s where the problem is.

I think we need to differentiate between the “business objectives” for the software project, and the actual business objectives of the stakeholders – usually expressed in language not related to software at all.

If you could describe your environment, maybe I could help identify a stable stakeholder objective?

Indeed – we have to walk before we run

Glad you liked it.

I envy you the industries and environments you work in where the business objectives have actually remained stable over the course of even a single software project. That has certainly not been my experience.

I’m looking forward to the post where you will reveal how we connect the dots between the business goals and our architecture

Thx for another great post.