Technical Topics

Data migration is typically the most forgotten or underestimated component of an IT project which is the process of making a copy of data and moving it from one system to another, preferably without disrupting or disabling active business processes. On some occasions, it is not easy to understand that a data migration is needed in the project and ...

With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble[1]. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.

Problems arise though when the critical front-end work is performed by programmers who are more in tune with technology than business. From their perspective, they see everything in terms of zeroes and ones, not in dollars and cents. Not surprising, they only think in terms of elegant technical solutions, not necessarily what is practical from a business perspective.

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.