What is success? Is it the culmination of a project? Is it the application of requirements? Is it the ability to enjoy the outcome of one's work and build upon it in the future? If you ask me, it's the latter because only when you can truly maintain and extend an application then the architecture has been a real success.
Often, business will try to justify a lower-cost or simpler solution on the basis that a program has a fixed life expectancy and that the business clearly knows what they want. They argue that scope will never change, cost today is more important than cost tomorrow, and we have to get it done yesterday. I've seen many projects built under these assumptions and they all have one thing in common: failure.
More specifically
Projects that are run like this are done so purely for immediate political expediency; and when these failure points come up, they are always politically painful to fix.
So, what is Success Oriented Architecture? Simply, it's an architectural philosophy with the following tenants:
Let's look at these one-by-one.
KISS, otherwise known as Keep it Simple, Stupid, is the rallying cry of lazy programmers everywhere. Why write ten lines of code when you can cram it into five? Five lines of code must be simpler than ten lines of code and must also be easier to maintain, etc. We've all worked with these people. You may be one of these people. These people could not be more wrong. About the simplest thing in the world is the wheel, but even the wheel needs an axle to be useful. To keep the wheel on the axle you need a pin. To keep the pin in the axle you need to bend it. To carry things on the axle you need a container. To lift the container off the ground you need a lever. Soon, you have a cart which is decidedly more complex than a simple wheel. All we have to do to see that the wheel in its simplest state isn't useful is to simply look at this example. Are we cavemen or programmers? We need to be able to realize that too much simplicity sucks and that it really is necessary to include design elements that add robustness to an architecture.
Readable code makes it clear what code does, and how it's accomplished; discrete actions are clearly seen and ambiguity is avoided. Let's look at some very hard to maintain code:
1: public class test
2: {
3: public static void main(string[] args)
4: {
5: Console.WriteLine(A.Calculate(B.InverseOf(C.MinValue(new D(args)))));
6: }
7: }
So, when you get a NullReferenceException on line 5, where are you going to find the bug? Can you even determine what variable is involved with the bug? Yet, in the name of "efficiency" or "simplicity" we see code like this all the time. Would we not be better serviced with code that fosters debugging and maintainability?
1: public class test
2: {
3: public static void Main(string[] args)
4: {
5: D d = new D(args);
6: var c = C.MinValue(d);
7: var b = B.InverseOf(c);
8: var a = A.Calculate(b);
9: Console.WriteLine(a);
10: }
11: }
Object Oriented Programming has three tenets: Encapsulation, Inheritance and Polymorphism. Each of these three individually allows you to create systems that are better than your standard bowl of C spaghetti, but it takes some planning to get the true value out of OOP; and that value is loose coupling.
Loosely coupled code is code that allows for changes to business rules, data format, and other strategic elements of a system to be changed or updated. The Strategy Pattern is a design pattern that specifically addresses this very concept. With loosely-coupled code, you can change your data access strategy, your logging strategy, etc by simply creating a new implementation of a well-defined interface and then changing the behavior of the application to use the new strategy's implementation. There are many good techniques for achieving loosely-coupled systems.
For years it was been popular to create client-server applications where a GUI was created that was loaded with business rules that were tightly integrated into even more business rules existing inside of the stored procedures of a proprietary database. There was little, if any, separation of duties between presentation, business logic, and persistence. It only took a few years in the 90's for companies to realize this was a pretty bad idea. Next came the great Internet craze which led to the replacement of client-server applications with web-applications which were basically a GUI with a bunch of tightly integrated scripting code residing in templating engines that talked to a bunch of business-rule laden stored procedures. If anything, we actually took a step backwards from client-server with this model because now we had the same horrible coding practices combined with a stateless interface that compounded every one of the problems created by client-server. Yet it was the web, thus it had to be better, right? Well, websites grew, databases became overloaded, templating engines overloaded and systems broke with glorious regularity and public humiliation. Now, when your crappy client-server architecture hiding behind HTML was exposed to the public, the whole world could see the results.
This was when people started paying attention to the concept of n-Tier development. It was obvious that loading up a templating engine with a bunch of business rules was a bad idea; but ask most DBA's and they'll tell you (wrongly) that it's perfectly OK to stick a bunch of business rules inside of stored procedures. After all, Oracle wouldn't provide stored procedures if they weren't the perfect place to put business rules, right? Overnight we abandoned ASP and CGI for JSP and ASP.Net. We moved business rules out of our HTML generators and placed them in shared libraries that happen to execute in the webserver. Was it faster? Yes, it was, and often increased the amount of traffic that a website could handle by an order of 10; but it was still brittle. All of that fast-moving webserver code now overloaded the database which was being burdened not just with the demands of fetching data, performing sorts, indexing new data, etc, but also processing those business rules that the DBAs insisted needed to be in the RDBMS. Business then started pulling business rules out of stored procedures and into libraries of compiled code on the webserver; which upset the natural balance once again. Now the webserver was tightly coupled to it's business rules, which were tightly coupled to their data rules, which were still tightly coupled to the database. Will the madness ever end?
Yes; and thank goodness it did. By the early 2000's it became clear that the real solution for business systems that could succeed over long life-cycles was to create systems that can be scaled both vertically by adding more strategic features, but horizontally as well by adding redundant processing capability. Distributed computing was not knew, but good techniques for it were. The advent of web services led to the liberation of the enterprise application from the domain of a few web-jockeys and DBAs into the realistic world of team development with real standards, contracts, and *gasp* design documentation. Now we can separate business rules from persistence and presentation. We can run these separated layers in a diverse set of hardware that provides for the best technology for a specific aspect of the system to be used. We have destroyed the brittle barriers that placed roadblocks between our needs and our success.