The reason is simple, anyone involved in Information Security needs a detailed understanding around how things work; where the dependencies are, the inner workings of programs and applications, who has administrative control over sensitive information, where the information is being stored, and how clients and programs interact with the data.

Performing threat risk assessments (TRA) involves an intimate understanding of a solution or service. This means everything from the pretty UI right down to the bits of code your development team scribed to make it look that way. 

The only way to understand these systems is via detailed communication with stakeholders, architects, business analysts, systems and network administrators, executives, clients and their technical resources, board members, vendors, ISPs, and the list goes on.

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.

If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).

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.