Showing posts with label Implicit Requirements. Show all posts
Showing posts with label Implicit Requirements. Show all posts

May 24, 2008

The Business Analyst and Enterprise Architecture

A business analyst or "BA" is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of [IT] services to the enterprise. (Wikipedia)

Business analysis is critical to enterprise architecture, because it derives the business functions, processes, activities, and tasks. Coupled with some basic data and systems analysis, BA determines the information requirements of the business and the systems (manual or automated) that serve those up. Through business analysis, we identify gaps, redundancies, roadblocks, and opportunities which are used by enterprise architecture to drive business process improvement, reengineering, and the introduction of new technologies.

Where does the business analyst reside in the organization—in the business or in IT?

The answer is yes to both. The business analyst resides in the business and works on segment architecture for their lines of business and on defining functional requirements. Some business analysts also reside in IT as a relationship manager to translate business-speak to the techies and vice versa. Also, the LOBs may not have business analysts on staff and may request this service be performed by the IT shop. For example, this may be done from the enterprise architecture function to support segment architecture development or alignment to the enterprise architecture. Or it may be done by the IT centers of excellence that develop the systems solutions. If they can’t get the functional requirements from the LOBs, they may send in their own BAs to work with the programs to help capture this information.

ComputerWorld Magazine, 12 May 2008, asks “Is there a place for business analysts in IT today?” And answers, “Not if their primary function is just to analyze business needs…business people want more than analysis; they want workable solutions.”

So aside from business analysis what do you need to come up with a technical solution?

  • Resources—$$$$, smart people, the right infrastructure! (this one’s mine, the other two below are from ComputerWorld)
  • Creativity—“come up with ideas…to create systems that can meet performance requirements.”
  • Synthesis—“best ideas are evaluated and modified until good solutions are found.”

According to the ComputerWorld article, a single person who does the analysis, the creativity, and the synthesis is called a systems designer, but I disagree with this. The analysis and development of the requirements is “owned” by the business (even if IT is called upon to help with this function). While the creativity and synthesis, which is the technical solution, is “owned” by IT. Further, it is typically not a “single person” that develops the requirements and comes up with the solution. The solutions provider (IT) is generally distinct from the business that has the needs, even if sometimes it is difficult for them to articulate these into functional requirements.

ComputerWorld specifies four techniques for identifying requirements and developing a solution:

  1. Group facilitation—“getting input from everyone who might have relevant information and insights on a business process.”
  2. Process mapping—“create diagrams that capture task sequences for existing and new workflows.” (I believe we in EA all know this as Business Modeling).
  3. Data modeling—“diagram the structure of the data those workflows operate in.”
  4. User interface prototyping—“use prototypes of user interface screens to illustrate how people can interact with the system to do their jobs.” (Frankly, I don’t believe this one fits with the other three, since prototyping comes somewhat down the road in the SDLC after conceptual planning, analysis, and design. I would replace prototyping with some core system modeling to fill out the business, data, and system model set, so that we can see what systems are currently in use and where the gaps and redundancies are, and where there is potential for component or system re-use and building interoperability.)

I would suggest that 1 and 2 (the facilitation and business modeling) are the functions are the business analyst, but that 3 and 4 (data and systems modeling) are the responsibility of the IT function. Again, it is the business that “brings” the requirements and the IT department that comes up with the technical solution to meet those requirements.

Another thought: Perhaps the organization is struggling with defining the business analyst and those that develop the technical solution because it is really the synthesis of the two that is needed. It is similar to enterprise architecture itself, which is the synthesis of business and technology to enable better decision making. I can envision the further development of segment and solutions architecture to become just such a function that merges the requirements (business) and solutions (IT).


Share/Save/Bookmark

November 25, 2007

Implicit Requirements and Enterprise Architecture

With electonic contact lists in Microsoft Outlook on the computer and on organizer programs on cellphones and other electronic gizmos, why would anyone still keep a physical Rolodex anymore?

The Wall Street Journal, 24-25 November 2007, reports that "some executives are still spinning their rotary card files...more than 20 years after the digital revolution that forecasted the paperless office, the 'rotary card file'--best known by the market-leading brand name Rolodex--continues to turn."

The article continues, "as millions of social-network users display their connectedness on their Facebook pages, a surprisingly robust group of people maintain their networks on small white cards. Most of these devotees also rely on BlackBerrys and other computer-based address books."

This infatuation with physical Rolodex files extends to models like the 6000-card wheel that are no longer even on the market. Other executives keep as many as 8 or 9 Rolodex wheels on their much needed desk space. Why?

The article states that "part of the card system's appeal has always been that it displays the size of one's business network for the world to see." Yet, social-networking sites like LinkedIn also display the number of contacts a person has, so what's the difference from a physical Rolodex file--what need is the technology not fulfilling with users?

From a User-centric EA perspective, it seems that people have a fundamental need with their contacts to not only be able to maintain them in an organized fashion and to demonstrate the size of their network (to show their value to the organization), but also to feel important and accomplished and to be able "to wear" this like a mark or medal of distinction, in this case by laying it out their Rolodex files prominently on their desks for all to behold.

In EA, when we design technology solutions, we need to keep in mind that there are functional requirements like the organizing of personal and professional contacts, but there are also human, psychological requirements that may never actually come out in a JAD session. These are unstated or implicit requirements and architects need to plan technology to meet both the explicit and implicit needs of users.

A little like Sherlock Holmes and a little bit like a psychologist, an architect must explore user needs beyond the surface if they are to successfully align new technologies with end-user and organizational requirements.
Share/Save/Bookmark