ACS Talk - How to do Requirements Analysis in Complex Integrated Agile and Waterfall Development Environments

Sorry for this very late post, I was going through my backlog and found some missed articles.

There are many different ways of approaching agile in business and architecture, as a result I am always on the look out for different perspectives and views. This is why I went to the talk on "Business Requirements Analysis - How to do Requirements Analysis in Complex Integrated Agile and Waterfall Development Environments" back on the 23rd May 2013, hosted by the ACS Business Analysts Special Interest Group (BRASIG),  as I do work in a mixed project  environment where I may be on both agile and waterfall projects at the same time. The presenter for the evening was Dr Asif Q. Gill from the University of Technology Sydney (UTS).  Dr, Gill is an experienced enterprise architect and after many years in industry now focuses on both teaching and researching enterprise architecture. 

The main focus of the presentation was on how and when to utilise the multitude of processes out there to manage from inception to realisation business requirements. It was an interesting presentation and he does put forward a good case for 'adaptive' processes. Rather then offering a hack-it-up as you go approach he offers a framework which allows for the inclusion of different agile process elements where appropriate for a business. 

As he noted, agile is easy to explain but can be hard to adopt. This is the first time ive seen a maturity model for agile presented. Gill has the Agility Adoption and Improvement Model (AAIM) which represents the various stages which a business progresses through as it adopts agile. It is in the slide pack but here is the stages of maturity he offers. 

Figure 1 - The Gill Framework Agility Adoption and Improvement Model (AAIM)

I think the adoption model has value, to track the process. The feedback I have had from different companies doing agile all assume that once they have a process that is under the Agile Umbrella, then the goal is reached. I doubt this is the case. 

References

• Presentation by Dr Gill
• ACS Business Analysts Special Interest Group
• The Gill Framework 
• Agile Manifesto Principles

SOA Services in ArchiMate

Nick Laqua  posted an interested discussion question on the LinkedIn ArchiMate group. It was a long post so I wont repeat it here. But it was interesting and worth responding in detail to. The key areas of the post I am looking at are

• How to model a SOA service within the application layer
• Emphasis the view of a service as defined by the behaviour and functions over the interface

The issue of governance is a larger one which really deserves its own post as the levels of governance on services will vary within organisations based on the company structures, roles, size and many other factors.

I have been doing allot of this recently, experimenting with a number of different approaches. This approach I have found most beneficial for myself and in the communication of services to others. When modelling an application service I start with behaviours. It is essential to know what has been identified as viable for automation. Remembering that all programs are simply the automation of a process, we need to clearly identify the scope of the service. In Nick's post he mentioned a Customer Management service which offers 4 operations. Create, Retrieve, Update,  and Delete. First thing that springs to mind is an Entity Service. We need to consider how granular we need to go. If we are describing a service with the CRUD capabilities for an entity we can pretty much guarantee that there will be more reads then writes, and based on different interaction needs of systems we will need to be able to show what is reading and what is writing. This level of granularity will help implement the security policy for the service, identify performance hot spots, for instance or allow improved impact analysis during the governing phases.

Are we offering one service or 4 services? At this granular level we are offering 4 services.

Fig 1 - Services as Application Services

These are all different services that the application offers. If you say, 'Well the application does offer a SOAP services isn't that the service?' the answer is yes, but it is the Technology service.

Interfaces are access points, and there may be many access points. Lets consider that the above services have been implemented via multiple interfaces.

Fig 2- Interface assignments

This clearly shows how the services are available from the CRM application via multiple access points. The interfaces here are separated only by the technology they use. It may be more appropriate to show this capability as tied to the 2 technology services, HTTP and RMI.

Fig 3 - Infrastructure Usage view

This is a good way to show what functions are tied to what infrastructure. I have left off the Assignment relationships between the component and the functions for clarity.

I prefer to use the former view with the multiple interfaces as you begin to add both more interfaces for UI and consuming applications, you will want to know which interface are they interacting with, the RMI, HTTPS/SOAP or UI? You cant do it with this view (Infrastructure Usage).

So I maintain technology referencing interfaces at the application layer. It allows me to show dependencies and function utilisation.

Fig 4 - Detailed services view 

Personally this is my preferred model. Its not always good for communicating quickly the utilisation of services as there is allot of information there to take in. By aggregating the CRUD services under single service you can get a simpler view with derived relationships.

Fig 5 - Simplified services view 

In the model the more granular services become aggregated within the larger object, but now I have lost the information about which specific services each function is using from the service and the assumption is generally the entire service.

Fig 6  - Visualiser from Archi showing element relationships are maintained 

I find the detailed view very useful for identifying gaps and changes that may need to be made. It also aids with identifying high demand services and can lead to separation of granular services into their own space for performance such as caching layers etc. While the Infrastructure Usage view is the more accurate description for the language, IMO, it is less helpful, especially for integration scenarios rather then just SOA ones.