"Enterprise Engineering" is a term coined in to reflect the third and final part of the concept of Information Resource Management (IRM) representing a triad of methodologies to design, develop, and control all of the resources needed to support the information requirements of an enterprise, be it a commercial or nonprofit endeavor.

Many organisations hire external consultants with no experience of their business to shape strategies and propositions. In doing this, they are unconsciously ignoring internal resource with exactly the same skills but additional knowledge and experience of the business – namely their Business Analysts. BAs have a unique skillset, offering holistic insight, analysis and recommendations.

Thousands of business analysts have turned to software visualization from as a strategy to simplify their jobs and cut through the confusion. With iRise, business analysts are empowered to quickly assemble a high-fidelity working preview of an application before development ever begins. These visualizations look and act just like the final product, creating an accurate visual model for what to build.

In many organizations, Centers of Excellence, PMOs (Program/Project Management Office) and PQA (Process & Quality Assurance) teams use a variety of manual techniques to vet documentation that are time consuming and manual; leaving room for unintentional mistakes, missed steps and delays in catching errors with regards to governance and best practices. In the spirit of delivering the project on time and under budget, many times these quality review processes are rushed and reduced to cursory checks. Like ensuring documents exist with the right naming convention, rather than reviewing the internal contents of documents and ensuring the contents are of high quality.

Almost every business analyst uses diagramming software in their arsenal of analysis tools. According to BABOK 2.0, an analyst’s traditional purpose in using diagramming tools is to “support the rapid drawing and documentation of a model, typically by providing a set of templates for a particular notation which are used to develop diagrams based on it.” Diagrams not only make requirements clearer to stakeholders through modeling, they help clarify an analyst’s thinking on a project through the process of their very creation.

Adoption of The Decision Model has escalated faster than anticipated. It also caught the attention of the Object Management Group (OMG) which is the subject of this month’s column. This column provides information to Modern Analyst readers regarding the OMG and its interest in decision models.

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.

I believe the Problem Pyramid™ provides the appropriate structure for guiding effective business analysis, both for initiating and carrying out projects, whether for what BABOK® v2 calls projects or for topics that truly fit within Enterprise Analysis.

A user of almost any given software system or business application will require precise analytics in order to objectively measure its effectiveness, or the effectiveness of an associated product. These analytics –or reports—therefore, must measure the right criteria at the right time(s) in the right way in order to be useful to the user. For that reason, any newly proposed reporting function requires careful, measured, thoughtful and thoroughly vetted requirements in order to ensure its efficacy.

While most business analyst roles don't explicitly require static modeling expertise, developing a better understanding of static modeling concepts can be a measurable forward step for business analysts seeking to develop new competencies. Such skills can be useful in many aspects of the BA work, from obtaining a better understanding of stakeholders' information needs, to documenting those needs in unambiguous ways and communicating them more effectively to the technical team.

Yes, the world is flat, and the reality of today’s global economy is that business analysts (BA) from all corners of the earth – North America, South America, Europe, the Middle East, Africa and Asia Pacific – often work with one another. But they don’t always understand how business efficiency is impacted by the comprehension of their inherent differences. There are fundamental philosophical and behavioral differences between professionals across the world that impact business success. If BAs aren’t readily capable of adapting to the environment in which they work, they are most certainly setting themselves up to fail.

For many business analysts (BAs), the IIBA Business Analysis Body of Knowledge (BABOK®) Knowledge Area that is the least familiar is Enterprise Analysis (EA). In some ways, this may be a mixed blessing. On the one hand, the BABOK® Version 2 (v2) EA area describes important topics and techniques that BAs should be conversant with: defining business needs, solutions, business cases, and project initiation. On the other hand, I have issues with the ways BABOK® v2 treats these topics, especially how it portrays business needs and considers defining them as only part of EA.

As part of the Unified Modeling Language, Activity diagrams are often utilized for many software projects. However, a few questions about Activity diagrams linger in the minds of many Business Analysts, such as: Who is really using them? What kind of projects are they being used on? Why are people not using them? How are people using them? Are they providing any benefit?
 

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.

In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.