Our team is looking at rolling out a new technology stack (enterprise wide) called Pega Rules Process Commander (supported by Pega Systems and considered to be top of the Gartner magic quadrant for BPM Suites). This being the beginning of the journey there were a few obvious architectural questions to address. I was particularly concerned about the base class structure knowing from experience that this is the part to get right at the start.
On a mission to get some answers I went along to the annual Pega symposium in Sydney in February. The clear steer I got from the Pega team (including Alan Treffler) was to hold true to an agile philosophy and allow the architecture to emerge. Meaning to build the initial application using as much of the existing generic structure as possible in the first couple of iterations. In the retrospective, determine the gap between where you want the structure to be and where it actually is. Use this knowledge to make conservative specialization decisions for the classes. Essentially this will instill an important re-use enabler discipline within the development team.
This seemed a little counter-intuitive to me especially since the first project was intended to be the first of many rolling this technology out as a core capability for the company. Who knows what the next business problem may look like? The cost of 'getting the class structure wrong at the start seemed far too high to dismiss. Now consider the alternative...
The natural counter approach is to design as much of the class structure upfront (using techniques like detailed business domain modeling)... This smacked heavily of waterfall and seemed to be the safest route... "NO!" I thought "I absolutely won't give in to that kind of fear driven logic!"
Digging a little deeper with some of Pega's other customers and with our sister company in Australia, I started to get a feel for the actual cost of changing our minds about the class structure and it appears this topic is well addressed. However it depends entirely on the development approach your team takes. Pega actively discourages waterfall when using their suite however this doesn't proclude customers getting value out if they're constrained by traditional SDLC views. It just means that the potential for re-use and agility is more likely to remain locked up.
Pega supports alterations to the base class structure and more importantly they actively promote a 'build for change' philosophy for implementers.
In summary, my opinion is that it comes down to a combination of an organization's outlook and risk appetite. If they're a bit more contemporary and understand the dynamics of innovation (i.e. learning frameworks such as SCRUM) then allowing the architecture to emerge is a 'no brainer'. On the other hand if the organization is still struggling with a traditional theory based philosophy (waterfall for example) then 'design upfront' will certainly ease anxiety and get things going.
================= LnkedIn Q & A ==================
I posted this question on LinkedIn and here are a few answers I got back:
From: Paul Williams
Colart,
I think that there's a balance. My most successful projects were front-end designed to a point, then evolved from that. In essence, the core -- backbone, if you will -- of the frameworks were designed cathedral style. The application modules, then, were "evolved", bazzar style.
Occasionally, a requirement of the application would necessitate an adaptation of the framework (or a really useful component would be promoted into the framework), and thus the framework also evolved, but always and only within the spirit of the initial design.
In contrast, the application components were ad-hoc, whatever you please to get the client happy.
From: Olaf Dietzler
I believe that the term "architecture" is actually defining a few basic principles.
- Stability
- Scalability
- Integration and interfaces
The point of having an architect (both for IT and buildings) is to at least provide a framework in which technology can support business changes, both in function and volume without the whole thing coming apart.
An architect doesn't neccessarily need to define up front what colour the walls are going to be or what flooring is beeing put into the building, but he should have provide walls (which can be repainted in different colours) and a level base, so that when the flooring is beeing placed (or replaced) without harming the foundation.
Regards,
Olaf
From: Tony Fairhurst
I find the best approach is to define a business strategy. What are the goals of the business over the next 2,3,4,5 years. Once this had been understood, you can produce a roadmap of how to get there. That doesn't mean you won't deviate from the roadmap, but at least you will know you have and why you have.
The Key for any EA is to build in, Agility, Adaptability, Re-usability into the big picture view. If these principles are adhered to then the evolution of the architecture should be positive.
I suppose on Philosophical perspective you can think of Enterprise Architecture along the same lines as Darwinian Evolution. Put the right building blocks in place upfront, and the entity will have a good chance of survival.
So, design in terms of the core principles and building blocks should take place, however, don't over design as this may constrain you long term, remember, none of us know whats going to happen in the future, and my experience is expect the unexpected!
One of the key issues to consider is the cost of getting it wrong. The higher the cost of having to restructure the whole thing the more effort needs to go into planning up front.
Consider the key message from Agile Development: "build the simplest thing that can do the whole job, and emphasis is on whole' (maybe I don't recollect the exact wording here). Even for something that is considered very evolutionary, the basic architecture needs to be right up front, or you're going to hurt later on.
There is no conceivable reason to discard what is known and make your architecture too simple, or impossible to scale or what ever you know it will have to do.
That said, you can often create your architecture such that it is extremely scalable, but not implement the scaled out version from the start.
To change your architecture (not your implementation details) usually requires a major rewrite of everything. As long as the cost is small enough, do it, but as the project / system grows, the cost of doing this also grows...
