Wednesday, April 27, 2011

Architectural Granularity

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.

7 comments:

  1. Interesting discussion, but there is also the issue of ownership. Components should be self-contained to be independently updatable, upgradable, maintainable and distributable in the distributed nodes of an EIS. Does the reservation component own the room entity? If it does then so do other components that need this entity. How then does the room entity evolve independently in these different components when it maps to the same database table? The only answer I can think of is 'with care'.

    ReplyDelete
  2. When building the Component Model I would always associate the underlying entities with one 'owning' component. I refer to these as the 'core business entities'. These, together with any dependent entities, would be managed through one component (to be precise the interfaces on the component). Other components that "need" this core business entity could only access it through the owning component.

    ReplyDelete
  3. If I understood correctly you suggest all entities of an application with their dependencies are collected in a component. But all other business logic application components are then coupled to this entity component, and the entity component itself has low cohesion (e.g. a Room entity together with a CreditCard entity being in the same component).
    From your experience isn't that problematic? Usually increased coupling and low cohesion are bad indicators. But maybe it is OK if the interface of the owning core business entities component that you describe is relatively stable. Can it always be stable? If it is rather stable then what do you think is the reason? Is it because entities are rather simple things lacking complex logic, which makes change requests for them few and simple?

    ReplyDelete
  4. Do you know of there is any attempt to establish a [defacto] standard "scale" for level of granularity?

    ReplyDelete
  5. Hi Chris, apologies for the lateness of my reply. Unfortunately I know of no formal or standards based approach to granularity. If you search the web, as I'm sure you have, there are many articles on the topic but nothing from any of the standards bodies that I can see. If it is important to your organisation or project then I would encourage a local effort at defining what best works for you.

    ReplyDelete
  6. Here is another view from some IBM authors: http://www.ibm.com/developerworks/webservices/library/ws-soa-granularity/

    ReplyDelete
  7. Hi Chris, hi Peter,
    we just saw your discussion her and what to shed a bit more light to your question of the level of granularity. We published the following research paper last year:
    Weber, M.; Wondrak, C. (2012)
    Measuring the Influence of Project Characteristics on Optimal Software Project Granularity
    In: Proceedings of the 20th European Conference on Information Systems (ECIS)

    Additionally, we are working on a web-based service to make the tools from the project available for software architects. You can find a preview/demo here: http://www.granu.com/

    Regards,
    Moritz

    ReplyDelete