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.
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.
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.
“I may not know much about art, but I know what I like”. This famous punch line to a Monty Python sketch about a fictional conversation between a disgruntled Pope and innovative Michelangelo (who wanted extra disciples, multiple messiahs and a kangaroo in his first draft of the Last Supper), can also be seen to satirize our own modern fixation with creativity, feedback and the idea that ‘the customer is always right’.
The benefits of Agile methods are becoming more obvious and compelling. While the most popular practices were developed and proven in small team environments, the interest and need for using Agile in the enterprise is growing rapidly. That's largely because Agile provides quantifiable, "step-change" improvements in the "big three" software development measures - quality, productivity and morale. Confirming Agile's benefits, hundreds of large enterprises, many with more than 1,000 software developers, are adopting the methodology.
Regarding software architecture, it's interesting to note that it is the "lighter-weight" Agile methods, specifically Scrum and XP, that are seeing the broadest adoption in the enterprise.
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.
Business Analysts are required to contribute to a project in a number of ways: primarily by identifying the needs of the target community; building the Communications Plan; defining use case models; and Business Requirements document. In order to do their job effectively a large element of a BA’s time must be spent understanding and managing stakeholders in the project... From a CIO’s viewpoint the skills they look for in a good Business Analyst include an aspect of stakeholder management and an ability to find a path through the likely problem zones.
This year, organizations will be picking themselves up and dusting themselves off, becoming more savvy, agile and proactive. Business analysts are well positioned to help organizations meet the challenges of putting their houses back in order by helping to answer the question: “How and where do we create efficiencies that will help mitigate the sting of another possible economic downturn?”
The Business Analysis Body of Knowledge (BABOK® 2.0) is the definitive guide to the profession of business analysis. Every business analyst can profit from it, and few analysts can afford to be without it.
Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.
However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels. In this whitepaper, we describe a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the largest software enterprise, while still providing a quintessentially lean and agile subset for the agile project teams that do most of the work.
Not unlike gardening, Enterprise Analysis takes very careful stock and consideration of the current state of your environment. By IIBA® definition, Enterprise Analysis is:
There are great shifts that happen in technology and culture. Sometimes they occur sequentially, as WWII created a need for advanced computing, and the PC forever changed the nature of work. Sometimes they happen concurrently, where pressures, both positive and negative, take place in tandem. We are in such a time of change now, with great crises and great opportunities for organizations and the people who love them. One of these challenges is the failure of Enterprise, Business and Technical architecture. Why do the Three Stooges so often stumble and fail?
When ModernAnalyst asked me to propose an article for their issue on Enterprise Architecture, I thought about the question framework developed by John Zachman, that provides the basic building blocks of that practice. The primary function of a Business Analyst is to ask questions that uncover requirements then to document those requirements so they may be developed into a useful, useable system.
As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: