Business analysts are at the sharp end of one of the great challenges of information technology – how to build the systems organizations need. At the same time, organizations are demanding more sophisticated systems – the “dumb” systems of yesteryear are no longer enough.
Business-process-modeling technology provides a powerful set of tools for describing and automating processes. The technology is so powerful that it often seems there are no limits to what BPM can do. But not every process that is automated needs BPM. Following on last week's discussion of process discovery, the JargonSpy asks the question: What sort of processes should be automated using BPM?
Businesspeople and technologists alike quickly get drunk on business-process modeling when they first become competent in the technique. Like wikis, business-process modeling allows you to capture the detail that you have in your head and then leave placeholders for what is not yet baked. In wikis, this takes the form of pages of text that link to other pages covering concepts that you will fill in later. Wikipedia is full of links to pages waiting to be completed.
The analogous act in business-process modeling is to put a box in to cover a step ("solve the halting problem" or "find qualified leads") that is part of the process but that you don't want to worry about just then.
Author: Dan Woods
If a single word can represent an entire year, then 2008 was the year of change. Of course, the next American president ran an entire campaign on change, but, more specifically, the business world as we know it will simply never be the same. We’ve all learned that no company—no matter how thoroughly it is woven into the fabric of the economy—is isolated from the need for improved efficiency, due diligence and corporate responsibility.
With change having such a profound influence on 2008, 2009 will likely be shaped by the business world’s ability to adapt to that change. And, of all the groups of professionals working today, few will serve a more important role in that adaptation than business analysts. Requirements management and development, which has for so long been the unsung hero of the successful project lifecycle, is poised to begin receiving the prominence it deserves.
Here are 10 key trends to look forward to in business analysis for 2009. They represent the on-going evolution of requirements management and development and the ever-increasing value of the modern business analyst.
If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?
We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.
When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.
Business Analysts rely on input from a subject matter expert (SME) to help complete scoping and requirements documents. This simple truth is the reason ModernAnalyst has asked me to share an overview of the Data Management Association Body of Knowledge (DAMA-DMBOK). The purpose of the article is not to teach you data management, but to provide you with a general understanding of building blocks of the practice. It will describe the breadth of subjects that data management professionals may be able to address.
The BABOK includes data modeling in order for a BA to document data requirements; this overlaps with the skills a data management professional needs to do data development. It is an obvious point of collaboration. When we examine all of the facets in data management, you may find other opportunities for leverage.
If you can recognize requirements that indicate impacts to the data environment early in your project, you can draw on other resources more effectively. I have provided some sample ‘red flags’ to illustrate requirements that might benefit from collaboration with a data management professional.
I suggest you develop your own list with the data management professionals at your organization; it will become helpful tool for you to know when to include them.
Does it ever feel like no one really appreciates what you do as an architect? It doesn’t matter what you’re designing, the consensus seems to be that what you do is just a lot of planning and thinking. No one seems to understand how much time and effort you have put into understanding every nook and cranny of the business so that your projects succeed not only from a physical deployment perspective, but from an organizational perspective as well. Essentially, your main role is to lay the foundation for your entire organization to succeed in business. Whether that’s from an enterprise, application, Service-Oriented Architecture (SOA), or other architectural design doesn’t matter. Your role is clearly one of the most pivotal in any organization, yet it's also one of the most misunderstood.
I say “one” of the most misunderstood because there is another worker bee in the hive who performs just as many pivotal yet misinterpreted tasks as you: the business analyst. As you work at defining the organization and deployment structures of your design, business analysts work at defining business problems and opportunities and turning them into solutions for customers. In other words, the business analyst is another key role that’s often misunderstood.
The misunderstandings occur because on the surface, it appears that both of you are attempting to do the same job. You—the architect—are undoubtedly the best person to design a practical solution for business requirements that you’re not particularly close to. At the same time that you are designing a solution, the business analyst—arguably the person much closer to those business requirements—is attempting to design a practical solution for them. Ultimately, you both want the same thing: a solution that works for the business and is cost-effective. The problem is that the two of you are coming at that solution from different angles.
Just imagine the possibilities if you and the business analyst learned how to put those angles together to form the perfect square.
Author: S. E Slack
The U.S. economy is bleeding jobs, but -- at least, so far -- the high-tech industry is something of a safe haven. That's not to say there haven't been tech losses or that it's easy to find an IT job. However, people with the right skill sets and the savvy to sniff out the particular areas of demand are much better positioned than professionals in some of the more-beleaguered industries.
...
Demand for IT business analysis is also on the rise right now, according to Rubillo, driven by a couple of different factors. Of particular importance in these recessionary times is the need for analysis that can wring out the most efficiency from a software application.
"Companies are increasingly aware of understanding the real world implications of an IT investment," said Rubillo. "A new software application, for instance, can result in bottlenecks in the supply chain, or a need for new resources -- or the ability to cut back on others. Companies want to get ahead of these developments as they implement their new IT investments."
Companies are also looking for untapped savings from pre-existing systems, he added.
Author: Erika Morphy
Billions of dollars earmarked for new technologies, at the same time billion-dollar projects are failing. Virtual teams who can’t implement Virtualization. Service Oriented Architecture when customers are no longer oriented towards your services.
Where can you turn to? Who can you trust?
Enterprise Business Analysis is the solution
EBA is Strategic, Process and Organizational Consulting: o Strategic – Planning and execution. o Process – the steps. o Organizational – the whole enchilada. o Consulting - Internal or external, the combination of expertise and intuition, Techne and Poesis, improvisation and practice in planning and supporting the enchilada’s goals.
You are already familiar with EBA, under its many masks for the diagnosis of the patient, and prescription for the cure:
Author: Sam Cherubin
Why has it been necessary to write so many different, book-length treatises about requirements management on software projects? Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts? At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project. In the appendix, I include a detailed example illustrating the key ideas.
Author: Theodore F. Rivera, Software Group Strategist, IBM
The problem of business-IT alignment is of widespread economic concern.
As one way of addressing the problem, this paper describes an online system that functions as a kind of Wiki -- one that supports the collaborative writing and running of business and scientific applications, as rules in open vocabulary, executable English, using a browser.
Since the rules are in English, they are indexed by Google and other search engines. This is useful when looking for rules for a task that one has in mind. The design of the system integrates the semantics of data, with a semantics of an inference method, and also with the meanings of English sentences. As such, the system has functionality that may be useful for the Rules, Logic, Proof and Trust requirements of the Semantic Web.
The system accepts rules, and small numbers of facts, typed or copy-pasted directly into a browser. One can then run the rules, again using a browser. For larger amounts of data, the system uses information in the rules to automatically generate and run SQL over networked databases. From a few highly declarative rules, the system typically generates SQL that would be too complicated to write reliably by hand. However, the system can explain its results in step-by-step hypertexted English, at the business or scientific level.
As befits a Wiki, shared use of the system is free.
Author: Adrian Walker
Good business solutions begin with good business analysis. But what's needed to excel as a business analyst and to get projects started on a good footing? Much has been (and will continue to be) said about the set of skills that go to making a good business analyst. Forrester Research, for example, has published a spreadsheet (called the Business Analyst Assessment Workbook -- Note: subscription required) that lists more than 150 attributes of a good business analyst, grouped into categories such as Core Capabilities, Business Knowledge, Job-Specific Skills, Technical Knowledge etc. (I was particularly pleased to see this last category: It is important but not quite obvious that business analysts should also have a rudimentary general understanding of technology environments and architectures… mostly built up through seeing past analysis engagements fructify into delivered solutions).
Although the workbook is obviously intended as an assessment tool, I also found in it good for use as a training tool — for example, to bone up on technology approaches to business needs and to study sample projects, correlating the original business requirement with the type of solution delivered. Here are 10 items from the Forrester list that I found particularly interesting and beyond the obvious (in no particular order)...
It has been just over a year since I published my book, and that makes it easier for me to measure what has happened since then.
I have spent this year visiting many companies and discussing their business analysis function. In some cases, I have performed an assessment on the business analysts as well as the business analysis function within many large Corporates.
It has now got to the point where I could document the findings before I start the investigation. The reason for this is that the problems are the same. From articles and discussions from other countries it appears the problems are similar the world over. These are the problems I encounter most often:
Here we are, the end of another year, and the question I ask always is, what have we learned? If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?
Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store. A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting. The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.
Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available? Each organisation seems to have its own ideas about the role, skills, responsibilities and expectations of the Business Analyst. Given the importance of the job, a common definition would assist both practitioners and employers. We explore some of the issues here. Written by Derrick Brown, IRM's Director and instructional designer, it shares first hand observations and experience gained from training thousands of Business Analysts since 1980, first in the UK and since 1984 in Australia.
Author: Derrick Brown
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: