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.

Nonetheless, it's a new year, and time to go back to work. January is when we reset the statistics, brace for a new year, and try to prove ourselves once again. Some people have trouble getting back into the swing of work after the holidays; they've probably slept too much, partied too much, and ate way too much, which explains the five-to-eight pounds they've put on. This is why dieting and temperance are among the top New Year's resolutions. Regardless, they are having trouble focusing on their work.

For almost 10 years we have enjoyed reflecting on what’s happened the previous year and making predictions for the upcoming year in the realms of Business Analysis, Project Management, and Agile. Some of the recent trends we have discussed: The digital BA, Lean business cases, BAs and PMs in a Dev Ops environment, BAs and PMs in the gig economy, etc.  Here are five industry trends that we have chosen for 2019:...

This article provides high-level steps for eliciting requirements when interviewing or holding a facilitated meeting with stakeholders; it was motivated by an attendee question at a recent Modern Analyst webinar: “Functional vs. Nonfunctional requirements.”  The question was, “Can a Business Analyst elicit functional and nonfunctional requirements in the same iteration?” 

When it comes to Predictive Analytics, several algorithms can allow you to use the available data by constructing a prediction model. Previously, we looked at a few algorithms designed to calculate probability. Another popular predictive analytics and AI algorithm is a Decision Tree known as C4.5.

Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump straight into a solution. However as BAs we first need to understand the problem area better.

As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the business analyst (BA). Below are some steps to help business analysts navigate their way through the transition to agile and add the most value to their agile teams.

Surely facilitation is an important part of a business analyst’s job, but it is far from the only part. Analysis in itself should always form the core of a business analyst’s responsibilities.  We are called ‘analysts’ for a reason! Facilitating information gathering and translating it to ‘requirements’ doesn’t make you an ‘analyst’. Go above and beyond, and add value by ‘reasoning backwards’ and ‘reasoning analytically’.

 

One of the Sidebars to the Business Agility Manifesto introduces the notion of Reconfiguration Agility. It’s a fundamental capability your organization needs in the Knowledge Age. What’s it about?  In the big scheme of things, you have two basic choices for conceiving, and ultimately implementing, business capabilities: procedural or declarative. They are fundamentally different.  Traditionally, the vast majority of business systems have been modeled and constructed on a largely procedural basis – virtually all things tied together step-by-step in processes. Unfortunately, that procedural approach simply doesn’t scale.