zapthink

Architectural Granularity

Peter Cripps architecture ,

There’s an old joke about defining granularity:Granularity is a bit like pornography, it’s hard to define but you know it when you see it.

The whole topic of granularity of software components is important to the Software Architect for a number of reasons:

  • If you are creating too many fine-grained components then you are probably not doing architecture but design.
  • As I discussed previously, getting components at the right level of granularity is important when it comes to placing those components (on nodes) and satisfying non-functional requirements such as availability and performance.
  • The granularity of components impacts performance. Too many fine-grained components will probably result in increased traffic on the network because the client using the component must make several queries to complete a task or get the information it needs.
  • Generally speaking, the coarser grained a component the more likely it is to have a direct correlation to something the business finds useful (e.g. a ‘Reservation’ component that handles all aspects of allowing a customer to reserve a room is more useful than one that ‘finds a vacant room’).

The terms “fine-grained”, “medium-grained” and “coarse-grained” are frequently used to describe architectural components (or indeed services) but there seems to be no common definition for these terms. This leads to confusion and ambiguity in their use. Whilst there is no agreed definition of what these terms mean there does seem to be a consensus that granularity is about more than just the number of operations an interface on a component has. Everware-CBDI (see their June 2005 edition which is only available via subscription) suggests that other factors might be (and I’m simplifying here):

  • The number of components (C) in the directed-acyclic-graph (DAG) that are invoked through a given operation on that components interface.
  • The function points (F) for each component.
  • The number of database tables (D) created, read, updated or deleted.

So one measure of granularity (G) might be:

G = C + F + D

Put simply, if a component is self-contained (C = 1), has a single function point (F = 1) and updates a single entry in a database (D = 1) it will have a granularity of ‘3’. Such a ‘component’ is going to be something like a class ‘Integer’ with a single operation such as ‘increment’ which adds one to the previous value. Whilst such a component may be infinitely reusable it is not particularly useful from an architectural (or business) standpoint. We could honestly call such a component ‘fine-grained’. At the other extreme a CRM system will probably have C, F and D each equal to several thousand giving it a granularity in the tens of thousands. Again, from an architectural standpoint, this is not very useful. There is not much we can do with such a ‘component’ other than observe it is (very) coarse-grained. I suggest that we architects are more likely to be interested in creating, and (re)using components that sit somewhere in between these extremes (maybe in the low 100’s region using this measure of granularity).

What we are actually talking about here is what ZapThink refer to as ‘functional granularity’ (as opposed to ‘interface granularity’) that is, granularity of the component itself rather than the granularity of any interfaces the component may expose. For the architect it is getting this functional granularity right that is most important. The coarser the (functional) granularity of the component the more likely it is to have a useful business context. So a ‘Reservation’ component that deals with all aspects of reserving a room for a customer (i.e. takes the dates, room preferences, hotel location, customer loyalty status etc) and finds a sutable room is a useful component at both an architectural level (i.e it addresses the points I started with above) as well as a business level (i.e. it is understandable by the business and can therefore be mapped to business users requirements).

When composing systems into components working out what level of granularity you need is a key aspect of creating the systems architecture so you have the right number of components that are most useful in both an architectural as well as business context.

EA Wars

Peter Cripps architecture , , ,

Lots of great discussion in the blogosphere right now on the relevance of Enterprise Architecture in the brave new world of the ‘extended’ enterprise and whether architecture is something that is planned or ’emerges’. This is largely prompted, I suspect, by the good folk at ZapThink asking Why Nobody is Doing Enterprise Architecture (possibly to plant seeds of doubt in the minds of CIOs and send them rushing to one of their “licensed ZapThink architecture courses”). For a nice, succinct and totally dismissive riposte to the ZapThink article check out David Sprott’s blog entry here. For a more reasoned and skeptical discussion on whether emergent architecture actually exists (I think it does, see below) read Richard Veryard’s blog entry here.However… despite some real FUD’iness on the part of ZapThink there are some elements in their argument that definitely ring true and which I have observed in a number of clients I have worked with over the last few years. In particular:

  • Emergence (i.e. “the way complex systems and patterns arise out of a multiplicity of relatively simple interactions“) is, like it or not, a definite factor in the architecture of modern-day enterprises. This is especially true when the human dimension is factored into the mix. The current Gen Y and upcoming Gen V are not going to hang around while the EA department figure out how to factor their 10th generation iPhone, which offers 3-D holographic body-time, into an EA blueprint. They are just going to bypass the current systems and use it regardless. The enterprise had better quickly figure out the implications of such devices (whatever they turn out to be) or risk becoming a technological backwater.
  • EA departments seem to very quickly become disjoint from both the business which they should be serving and the technicians which they should be governing. One is definitely tempted to ask “who is governing the governors” when it comes to the EA department? Accountability in many organisations definitely seems to be lacking. This feels to me like another example of gapology that seems to be increasingly apparent in such organisations.
  • Even though we are better placed than ever to be able to capture good methodological approaches to systems development I still see precious little adoption of true systems development lifecycles (SDLC’s) in organisations. Admittedly methods have had very bad press over the years as they are often seen as been an unnecessary overhead which, with the rise of agile, have been pushed into the background as something an organisation must have in order to be ISO 9000 compliant or whatever but everyone really just gets on with it and ignores all that stuff.
  • Finally, as with many things in IT, the situation has been confused by having multiple and overlapping standards and frameworks in the EA space (TOGAF, Zachman and MODAF to name but three). Whilst none of these may be perfect I think the important thing is to go with one and adapt it accordingly to what works for your organisation. What we should not be doing is inventing more frameworks (and standards bodies to promote them). As with developing an EA itself the approach an EA department should take to selecting an EA framework is to start small and grow on an as needs basis.

Enterprise Architecture is Dead. Long Live Interprise Architecture

Peter Cripps architecture , , ,

ZapThink have recently been drip-feeding a series of ZapFlashes predicting the end of Enterprise Architecture (possibly allowing them to derive some further consulting/education business by creating a little fear, uncertainty and doubt). Here are some of their predictions and my thoughts. Comments welcome.

  • The secret to 21st century software innovation. Is, according to ZapThink, in harnessing the power of complex systems (i.e. rather than just enterprise-wide systems). A complex system is one that shows some form of emergent behaviour where the properties of the system as a whole exhibit behaviour that the individual components do not. Most people don’t get this confusing systems that are just complicated with ones that are complex. For me this is spot on. As the enterprise morphs into basically the whole of the internet traditional governance models breakdown. The boundaries of the enterprise can no longer be nicely defined and who is in the enterprise and who is not becomes harder to pin down. People who get this and who can successfully harness the “interprise” (my new word of the month) by using the positive effects of social networking etc will win out over the next few years. Of course this involves huge risks not least of which around how will enterprises keep control of their data and intellectual capital.
  • RIP enterprise software. Enterprise software as provided by the large package providers is seen as large and inflexible and not delivering on the benefits promised by SOA. Companies are finding themselves encumbered with expensive and hard to maintain software they can’t “bend” to do what they want. ZapThink’s take is that whilst enterprise software may have failed SOA has also failed to deliver on its promise of providing flexible business processes that can be quickly adopted to new needs. My take is that like everything else in our industry nothing is given chance to bed in before the next wave comes and sweeps everyone along with it. Many clients I see are still grappling with getting an effective process in place for developing traditional systems let alone service-based ones and definitely cannot deal with complex systems properly.
  • The beginning of the end for Enterprise Architecture frameworks. Architecture frameworks (especially enterprise ones like Zachman and DoDAF) are counterproductive to developing an effective EA strategy. These frameworks are inflexible, sometimes encouraging what ZapThink refer to as checklist architecture. Checklist architecture focuses on achieving goals laid down by the architecture framework rather than the changing needs of the business. True but having no framework at all leads to even greater chaos in my experience. A framework is a structure which is meant to contain relevant guidance and work products to deliver real-world solutions. Frameworks that become too theoretical are always doomed to fail as they should. I hope this forms the basis of something more relevant to the real world.

So how would I characterise “interprise architecture”?

  1. Interprise architecture recognises that it is not enterprise architecture that is dead but trying to constrain architecture by the bounds of the enterprise that is no longer achievable. The ‘architecture’ bit still applies, but not the ‘enterprise’ bit.
  2. Governance models need to recognise that this extended enterprise includes people and other systems that are not controlled by the IT department (people using social networking software who will periodically ‘overlap’ with the enterprises systems).
  3. The ‘architecture’ bit needs to take into account the fact that systems are complex (in the emergent sense of the word) and it’s not always possible to tie down the requirements in a nice orderly way. Indeed fully defining the requirements may be counter-productive and not allow emergent behaviour. Processes for developing such complex systems need to take this into account.

To be sure this is not a complete list. This idea is not yet fully-formed in my own mind and needs a bit more time to ’emerge’ properly. Watch this space as they say.

Are Frameworks Too Constraining and is Chaos the Natural State?

Peter Cripps architecture , , ,

ZapThink have recently published a number of good articles on complex systems, the death of Enterprise Architecture and the dangers of ‘checklist architecture’. These have resonated nicely with some of my thoughts on the state of (IT) architecture in general and whether we are constraining ourselves unnaturally with the tools, processes and thinking models we have created. Here are the problems that I see we have with our current approach:

  1. Systems are getting ever more complex but we are still relying on the same-old-processes to deal with that.
  2. We have processes which are too large, overblown and themselves too complex which lead to people being driven by the process rather than the business goals for the system(s) under development.
  3. We are creating siloed professionals who are aligning themselves to particular disciplines; for example: Enterprise Architect, Solution Architect, Integration Architect the list is almost endless! This results in sharing of responsibilities but no one person or group retaining the overall vision.
  4. The majority of enterprises faced with addressing these challenges themselves have such large and complex bureaucracies in place that the people working in them inevitably end up becoming ‘inward facing’ and concentrating on their own needs rather than solving the complex business problems. There is of course an interesting dichotomy here which is: do we develop systems that just reinforce the status-quo of the systems we live by?

What we need is a new approach which both encompasses the need to address the complexity of systems we must build but at the same time allows for the change and chaos which is almost the natural state of human affairs and allows new and interesting properties and behaviours to emerge. As I’ve said elsewhere what we need is a new breed of versatilists who, just like the Vitruvian man of Leonardo da Vinci, can bring to bear a whole range of skills and competencies to help address the challenges we face in building todays complex systems. I think what we need is an update of the agile manifesto. This won’t just address the relatively narrow confines of the software delivery processes but will be far more extensive. Here is my first stab at such a manifesto.

  1. Systems of systems rather than single systems.
  2. Business processes that provide automated flexibility whilst at the same time recognising there is a human and more collaborative element to most processes where sometimes new and unexpected behaviours can emerge.
  3. Adaptable and configurable software delivery processes that recognise business requirements are dynamic, unclear, and difficult to communicate rather than a single, monolithic ‘one size fits all’ approach that assumes requirements are stable, well understood, and properly communicated.
  4. People that objectively view experiences and reflect on what they have learnt, look further than their current roles, explore other possibilities and pursue lifelong learning rather than those that focus on the narrow confines of the current project or how to better themselves (and their employer).
  5. Enterprises (whether they be consulting companies, product developers or end users or IT) that recognise the intrinsic value of their people and allow them to grow and develop rather than driving them to meet artificial goals and targets that feed their own rather than their clients/customers needs.