Technical Topics

An activity diagram is a type of flowchart that is part of the UML (Unified Modeling Language) standard. Its purpose is to enable analysts to present a concrete, easy-to-follow visual of the workflow of a business use case.

Mobile application development is hot. Smart phones and tablets sales are exploding, and technical teams are exploring ideas for new applications. With new development work, sometimes roles like Business Analysis get left behind as programmers rush to code a new mobile app. Even when we’re in a rapidly changing industry, taking a bit of time to work on design is still important. In fact, it can be the difference between an application that is used and one that is discarded and left behind.

For projects that may well be delivered by Service Oriented Architecture (possibly using Service Oriented Analysis), I would suggest that you may need to consider different or additional ways of documenting your requirements and specifications. The reason for this is that the way you shape your requirements needs to encompass both the holistic nature of SOA, as well as the new terminology and delivery mechanisms.

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

Although you can do ‘standard’ requirements gathering for Service Oriented Architecture (SOA) projects, there is now an evolving a set of analysis techniques, methods and approaches that purport to be better suited to information gathering and design specification. I will call these generically Service Oriented Analysis.

We are often asked what you need to do to run a successful SOA Pilot. Based on our experience of dozens of pilots, I propose that the following characteristics are essential to success.

It is unfortunate, but not surprising, that the elegant and relatively simple view of SOA has become bloated with a bewildering array of methodologies and products, leading to confusion and bafflement by many of its proponents and potential converts.

So far in this column on SOA for Analysts, I have talked about the use and re-use of services as building blocks to put together new or better business applications. Now you are getting familiar with this concept, I need to peel away a layer of the SOA onion and expose you to a few tears by revealing this as a half-truth.

We are witnessing a marked increase in both the importance of and focus on the work of the business analyst that is directly proportional to the depth with which cloud computing services are utilized. What's more, we are experiencing a shift in the tools and skills that our analysts and those of our customers are required to utilize.

Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.

Much of the current buzz about SOA has been focussed on the technology (inevitably Web Services) or the importance of reusability. However the real value of SOA is in the improvement to processes and ways of working that reflect the alignment of an organisation with its customers and suppliers.  The approach we favour is one that begins by aligning the business and technical understanding of the concepts of SOA, from both the business process and technical architecture perspective.
 

Most analysts are introduced to SOA in one of three ways; two of which are potentially painful and one of which is actually useful. I’ll let you decide which you would prefer.

Like any other religion, sorry architecture, SOA has its own language and meanings for the terms it uses. Unfortunately, some of these words can be very confusing, none more than the term "service". So here is a bluffer's guide to understanding and conversing in SOA-speak.

If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).

Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.