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.
In recent years it has become more and more apparent that the job description of Business Analyst has become diluted and distorted. Can this be considered the natural evolution of a profession or is it a profession that no longer has a clear job description? Is this a profession that has moved past the point of clear boundaries or are the boundaries still there but blurred based on the need to adapt to a changing world to meet the needs of people rather than the needs of the business? What can we do to win back the respect that the Business Analyst profession deserves? Exactly whose responsibility is it to maintain a professional and respected image of this profession? Should the recruitment process of Business Analysts be an exercise in requirements gathering?
If it is allocating your internal resources, making a new hire, or bringing in a consultant; what is the best process to match the right business analyst to the right project? For organizations that truly value the role of the business analyst this is one of the most frequently pondered questions.
Companies that want to have the right people in the right roles need to address four main stages; defining the BA’s roles in the project, attracting the best talent, matching the BA to the project and finally, making the selection and continuing to support.
As an agile analyst, you know how easy it is to get lost in a blizzard of project details. The way to keep focused is to remind yourself of the chief reason for using agile processes: to deliver business value for your organization. With that in mind, we’ll look at specific ways you can combine two approaches: agile and lean.
When I’m not consulting or managing projects, some of my time is spent teaching MBA classes at Drake University. The fact that I teach both project management AND creativity for business creates consternation among some of my friends and colleagues. After all, can a project manager really be creative? Aren’t those mutually exclusive skills?
My response is a great project manager also must excel at creativity to remain a viable, valuable asset in today’s marketplace. Gone are the days of simply managing scope within a budget and schedule; project managers must be multi-faceted utility players. Project and program managers are being expected to create solutions, to facilitate conflicts, and to motivate resources toward a goal in ways never before anticipated.
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
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: