How to align software with business processes?

Question

In my experience, software that is well aligned with business processes are easier to change when the business processes change. What type of architecture is best suited for this approach?

Answer 1

Glib answer: an enterprise architecture.

What sort of answer are you really looking for? In my experience, each business has unique needs, especially when it comes to the directions they want to evolve in. Modifiability is just one of the desirable qualities, competing for resources with cost control, time to market, efficiency, security, usability and the rest of the gaggle.

Answer 2

Good question... But first... SOA? That is a great buzzword but is often misunderstood, largely due to the lack of any one "real" definition. Heck! even Martin Fowler now refers to it as "ServiceOrientedAmbiguity" and encourages people to avoid bringing it up at all.

There really is no "one" "best" answer. The demands placed on IT by businesses can be; and usually are; quite varied. These demands are often influenced by external drivers such as customers, partners, market trends, legislation, regulators, etc. In many cases these drivers dictate architecture, or at least compromise or constrain your ability to fully acheive what you feel might be a "better" architecture. That may also sound glib, but that is not my intention. The notion that there is such a thing as a "best" architecture leads many to continue to waste huge amounts of energy (and money) in its pursuit. Although it may not be intentional, these perspectives are often backed by people who have become proxies for a single vendor/community, or are selling you a process as a product.

With all that said... from a software engineering perspective, the old tenets continue to remain the most reliable means to ensuring you can meet business demands. For example,

• Seperate your concerns
• Layer your architecture
• Design with flexibility in mind
• Test layers in isolation, and then test them together
• Employ Continuous Integration practices to make regression visible sooner
• Make requirements and specifications your primary drivers
• Invest in tooling, invest in your developers
• Etc...

Notice there is no mention of any one architectural pattern, technology, or language... that's because these aren't really the drivers, although they may be the enablers and will change given a variety of factors. Let me touch on one more point. "Business Processes" and software engineering processes have very different concerns, perspective, etc... Forcing either group to function the same as the other will only lead to utter failure. That's not to say they shouldn't share commitments such as dates, functional deliverables, etc. These groups need to be different to do their job effectively, but certainly need to find ways to communicate those things that require a shared vision. This is where any number of design and lifecycle management processes can help. (Ex. DDD, MSF, SCRUM, CMMI, etc...).

I meant this to be constructive... hope it helps.