In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here. Over the years, though, people have leapt onto the bandwagons of numerous new software approaches. They all have merits, they all have limitations, and they all need to be applied to appropriate problems.

Our job is to be trusted advisors and one area where we can establish trust is to help our stakeholders understand language that might be confusing to them. In order words, we can establish trust by translating technical complexity into business language. We BAs have always done this. We take customer requirements and translate them into something the technical folks can understand…and vice versa.  But what about translating in the digital world? We still need to translate, but it’s different. It’s more complex. 

We live in a time when business in many industries offer similar products and use comparable technologies. One of the last points of differentiation are processes, and the evidence is clear, in sector after sector: companies that figure out how to combine business domain expertise with advanced analytics to improve their internal and customer-facing processes are winning the market.  Let’s take a look at three of the many opportunities that the advanced analytics technologies developed over the past decade are creating for business analysts..

DevOps is based on a culture of trusted partners. This partnership is between software development, quality assurance, security and controls, and operations. The result is a smooth and fast transition of software from development to operations. However, like Dover, if the trusted partners are somehow reorganized into formal handoffs each with their own software acceptance procedures, the movement of software is no longer smooth nor fast.

One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s definition of ‘elicitation’ is “An activity within requirements development that identifies sources for requirements and then uses elicitation techniques to gather requirements from those sources.”

However, this definition appears incomplete from an analyst’s point of view as it relies solely on the assumption that one can come up with requirements only by running elicitation techniques; however, the process of elicitation is not as simple and straightforward as it seems. Let’s see why.

This article describes the process of the strategic enterprise analysis utilizing text and tables. In the past 5 years, things have changed, and I have gained new insight and most important learned new aspects. As a result, this article expands previous material to include...

In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.

Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here

On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.

Personally, I believe the best approach to enterprise risk and security management (ERSM) is to rely on several open standards, most notably the ArchiMate standard for enterprise architecture modeling, as well as the Open FAIR standard for information risk management. More details are described in The Open Group’s white paper on modeling enterprise risk management and security.

The function of a technical business analyst is to bridge between business and technical teams. This can be undertaken in various forms. First, the bridging can be done by translating business requirements into technical artifacts. The analyst must be able to assess the business and note the basic requirements of that particular business at that given time. Using their skilled knowledge in technology they must be able to translate the given come up requirements into technological terms. The requirements must, therefore, be taken care of technologically for efficiency and accuracy.

While many business analysts may be able to get by without ever writing a single line of code, the ability to write and interpret SQL queries can greatly increase your effectiveness as a BA. The purpose of this article is not to provide a tutorial on learning SQL, however, it is to demonstrate how SQL can be used in various business analysis techniques without having to rely on more technical roles such as data analysts or developers (they have plenty of other things to do).

No matter what type of project you’re working on, how big your team is, or what your specific processes are like, you can apply these 5 steps to help you manage the day-to-day events that get you to the finish line. They help you cover the bases by assessing the project status, planning proactively, reacting appropriately, connecting your work with others, and following up with the team and clients.

 

The design of major systems need not be a complicated process couched in a cryptic vocabulary using seemingly esoteric techniques. While the state of the art in programming has undergone considerable changes over the last half century, little progress has been made in the area of systems which has stagnated due to the lack of standards and the heavy emphasis on programming.

If you have some experience in modeling real-life, full-size architectures for large-scale organizations – preferably in the ArchiMate language, of course – you have likely come across the challenge of organizing your models in logical and manageable ways. In the following pages, we’re going to share our top 6 ways to organize your architecture models. These methods should help you keep your models neat and tidy, while also supporting better outcomes for your strategic initiatives. Let’s see what they are.

With the increasing growth in knowledge and information about the aspects of Business Analysis and technical analytics domains, there is a notable increase in confusion when it comes to the real difference between Business Analysis and Technical Business Analysis. In fact, the two are often used interchangeably. However, the differences between the two practices are prominent. In this article, we will discuss each practice and the set of skills required to claim being a business analyst or a technical business analyst.

Strategists, architects, process experts, software developers, data managers and other professionals involved in changing the enterprise often put substantial effort in creating all kinds of useful models of their designs. In many cases, such business models, enterprise architecture models, business process models, software models, or data models are only used to specify some design, i.e. to describe what should be built. 
But there is much more value to be had from these models, by using powerful analysis techniques to elicit new insights. In the following pages I will cover 7 of these analyses, discussing the business outcomes you can achieve with their help.