Technical Topics

It is important to illustrate most of what goes on in the systems and software world is really not as complicated as people make it.  Most of what we do in business is process transactions, representing some sort of action or event, such as a purchase, a return, a back-order, a debit or a credit.

Every now and then I encounter a programmer who adamantly contends you cannot have an information system without some form of computer support. Actually, we've had such systems well before the advent of the computer.

The purpose of this article is to assist business analysts in writing business requirements. This article provides six guidelines on technical writing. The six I cite here are the major ones I consider when writing a business requirements document (BRD).There are, of course,other technical writing guidelines; for comprehensive texts, see Further Reading (1). 

This article describes the Entity Relationship Diagram that allows you to document the structure of a database in terms of persistent entities and the relationships between them.  The Entity-Relationship Diagram (ERD) provides a way of graphically representing the logical relationships between entities in order to create a database schema to persist those entities.

At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or - if they only deal with requirements investigation - then someone else in the team will need to verify that the data to support new functions will be available.

There are considerable benefits from extending business process management capabilities outside the boundaries of the company, and clearly measurable value is much easier to quantify when stakeholders are outside the traditional walls of the business.

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.