Google



1










What Is Business Analysis? to Business Analysts

What is Business Analysis?

What is business analysis?

In very basic terms, business analysis could be said to be the application of a range of disciplines, to determine business needs and develop solutions to business problems. Of course, in practice this short description becomes entirely inadequate, a far more exhaustive explanation is required to explain exactly what business analysis actually is.


Business Analysis Basics


Business Analysis is a term which refers to the process of firstly identifying the needs of the business and then developing and implementing the solutions to meet them. Business analysis techniques are applied to develop an appropriate plan and then put it in to action. Business Analysts are an important asset to every business, they apply their skills to take the big picture and break it into smaller parts, making it easier to ensure that company resources are being utilized in the most efficient manner.



Business Analysis is Goal Orientated


Business analysis always focuses upon goals, but in a bi-directional fashion. Business analysis can be implemented to both set goals, and to achieve them. These goals will cover strategic business practices encompassing IT, business processes, corporate policies, structure and trading strategies across the entire enterprise.





Business Analysis Is Comprised of
Three Core Elements


The term business analysis is a broad term given to the process of analyzing and influencing three distinctly different aspects of the business, which combined, effect the enterprise at every level, these are:


Business Analysis Techniques


Depending upon the market sector the enterprise sits within, different business analysis techniques will be applied. Different techniques may also be applied at project level. Some of the most common of these techniques are:


These are just a handful of the mainstream techniques which make up the toolset of the modern business analyst. These are very succinct descriptions, each of these techniques is worthy of several pages of description in their own right.


The Three Phases of Business Analysis


Every time that business analysis techniques are applied, there is a natural three phase progression, which can be explained thus:



Why is Business Analysis Important?


Business analysis is important for many reasons, although the main one should be quite apparent; business analysis allows a company to take carefully iterated steps towards achieving greater profitability by working


Every enterprise is the sum of its stock value, working capital, tangible assets, customers, staff and goodwill. By employing modern business analysis techniques, the value of each of these core aspects. Hopefully this has answered the question of what is business analysis.




© 2015 Stellar Force

Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst

What's the Difference between Business Development, Sales Development, and Bu...
by Limor Wainstein
29 Jan 2018 at 3:09pm

Business development broadly refers to activities that create long-term value for an organization by implementing growth opportunities for an organization, such as forming a partnership that helps sell a product in a new market.


Sales development, while closely related to business development, is a separate area that entails creating value for an organization by identifying, connecting with, and qualifying leads, moving the prospects most likely to make a purchase towards the back end of the sales cycle where they can be closed by a salesperson.


Business analysis is more focused on identifying a need for change in how businesses work and helping to facilitate such change, whether by streamlining existing processes or implementing new technologies and new ways of doing things.   


The rest of the article highlights the similarities and differences in these areas, overviews the main roles involved (sales development representative, business development manager, and business analyst), and discusses some of the important skills for each role.

Differences & Similarities

Business development resembles a sales role in that it involves working to acquire new customers and clients for a business.

Business analysis is quite distinct from the other two areas because it requires a lot of data and research into how the business operates as a whole, as opposed to focusing on marketing/sales.

Business development focuses on sales from the perspective of expanding an organization’s reach into new markets, while sales development focuses on generating new sales from existing markets.

Business development can be seen as a high-level sales job, while sales development is more entry-level, and there is a path between the two areas, with business development staff often beginning in sales development roles.

Since business development impacts stakeholders, business development decisions will often include the input of the business analyst.

Sales Development

The key role within sales development is that of the sales development representative. A sales development representative is responsible for outbound prospecting. More specifically, the sales development representative receives a list of leads from marketing, who he/she is then responsible for contacting and qualifying so that closers spend more time selling to the prospects that are more likely to make a purchase.


Skills required:


Actively listening to people to best determine how to ensure you meet their needs, rather than aggressively trying to move people along the sales pipeline.

Familiarity with or ability to learn how to use CRM platforms.

Resilience: it’s important to maintain positivity when a phone call or email to a lead does not turn out as planned. SDRs must be able to quickly move on from a bad phone call or email and show the same enthusiasm for the 20th prospect contacted in a day as the 1st.


The salary for a sales development representative varies quite markedly depending on location and experience level.

Business Development

A common role in business development is the business development manager, who is tasked with helping a business grow by acquiring new customers or markets to sell to and selling new products or services to existing customers. The overarching task is to diversify a company’s clientele.


Some important skills required are:


Excellent interpersonal skills and the ability to persuade/influence people.

Strong sales and negotiation skills for developing partnerships and expanding a company’s reach into new markets.

An eye for new business opportunities through attending industry conferences and other events.

Building positive relationships.

Writing detailed reports for presentation to senior management.


Business development managers earn a median annual salary of $71,248 in the U.S.

Business Analysis

A business analyst often acts as a link between an organization’s stakeholders and its processes. The idea is that stakeholders define their needs and the business analyst then takes responsibility for translating those needs in terms of business processes and technologies that can help deliver what stakeholders want.


While some professionals such as data analysts and process analysts perform business analyst activities in their daily work, many organizations employ a dedicated business analyst. In fact, there are sub-types of business analyst roles that focus on IT, for example, or a business systems analyst. One can also become a senior business analyst.


Key skills:


Creating concise requirement documents for improving processes and implementing technology solutions that help meet stakeholder needs.

Data visualization and other visual modeling skills that help to capture and convey information visually.

Ability to form strong relationships with stakeholders.


The median business analyst salary is $59,291 in the U.S.

Closing Thoughts

While sales development, business development, and business analysis involve distinct roles with specific skillsets, there is an overlap in many areas. Sales development and business development are closely linked, as are business development and business analysis.


There is, therefore, the opportunity to carve out a career path starting with becoming a sales development representative, moving to business development, before upskilling to become a business analyst.



Does Agile need Architecture to be successful?
by EA Learning
23 Jan 2018 at 9:21pm

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.


A Day in the Life of a Business Analyst / Marketing Analyst - Differences, Ro...
by Limor Wainstein
7 Jan 2018 at 5:00am

Business analysts typically gather and interpret data from many areas within an organization, finding solutions to business problems and improving business processes with all that data. A business analyst may measure and improve on such disparate things as warehouse efficiency and cloud software implementation.


A marketing analyst, on the other hand, studies quantitative data gathered specifically from a company’s marketing activities, such as customer behavior and social media signals, in order to better optimize marketing strategies.


With the swathes of data collected by Big Data systems and marketing tools at companies of all sizes, marketing analytics is expected to explode. One popular annual marketing study—the 2017 CMO Survey—forecasts a 229 percent increase in marketing analytics spending over the next three years.


In this article, you’ll find out about the differences between a marketing analyst versus a business analyst. You’ll also get informed on the roles and responsibilities, and the types of marketing tools, business intelligence tools, and other software that each must use in their respective jobs.

Roles

Let’s take a look at the common responsibilities and skillsets for these two roles separately.


Business Analyst

Business analysts have much more varied roles than their counterparts in marketing. More specifically, such people are usually responsible for or required to be skilled in different things than marketing analysts for their daily work, including:


Business analysts typically require knowledge of statistics and statistical software such as R. Companies also look for SQL knowledge in their business analysts.

Business analysts can work in projects with accounting, finance, IT, and marketing teams.

Business analysts are responsible for high-level reporting on entire business processes/domains involving multiple data sources.

Business analysts design solutions to problems for the business as a whole, and thus must effectively be able to communicate with many business areas.


Marketing Analyst

Marketing analysts frequently have the following specific skillsets and responsibilities:


Marketing analysts should be good with Excel and understand statistics. They also require excellent knowledge of all marketing tools the business uses.

Marketing analysts work closely with other marketing staff, making sure that all campaigns are tagged and tracked properly.

Marketing analysts build dashboards and reports based on web analytics and other marketing metrics.

Marketing analysts mostly communicate with marketing staff, sales staff, and developers.

Tools

Both marketing analysts and business analysts extensively use a slew of different software platforms in their respective jobs.


Business Analysts

As mentioned, SQL knowledge is much sought-after for business analysts. SQL is a language for managing data held in relational database systems. Business analysts would not require the same level of SQL knowledge as, say, an actuarial analyst, but a fundamental understanding of its capabilities and basic functions is vital.


Additionally, business analysts often use data visualization and business intelligence tools, such as Tableau or SAP BusinessObjects.


Marketing Analysts

Marketing analysts must understand fully all the different marketing tools deployed by the company they work for. This means knowledge of marketing automation and email marketing tools. This source extensively overviews the main marketing tools companies use. Marketers will work with web analytics tools such as Google Analytics and Kissmetrics to get insight into the behavior of prospects. See this wiki providing an overview of the types of marketing tools these professionals use every day.

Differences

Some aspects of both roles lend them well to transferability—marketing analysts are well-placed to become business analysts and vice versa. However, there are important differences that will require a learning curve, including:


Both roles require a good grasp of statistics but the data sources and uses will change. Both roles differ in terms of interpreting what the numbers mean—marketing analysts need to understand numbers in the context of improving marketing strategies while business analysts need to think of streamlining entire business processes from a stakeholder’s perspective.

Marketing analysts will require additional communication skills because a business analyst must communicate with many departments, meaning solely speaking in marketing terms will not suffice.

Business analysts focus on “bottom-line” metrics and KPIs while marketing analysts emphasize metrics indicative of successful marketing strategies and campaigns.

Business analysts are concerned with improving IT architectures as a whole, but marketing analysts just want good marketing tools that work together.

Closing Thoughts

Both roles offer diverse career paths, good salaries, and plenty of opportunities for work. It’s imperative to note that choosing one or the other doesn’t mean you are stuck doing that job forever—working at either of these roles provides valuable skills that you can use if you want to change between them.


Business Architecture in an Agile World ? the What and the How.
by EA Learning
4 Jan 2018 at 4:29pm

My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.” This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!

Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.

The principles of Agile are very straightforward. Agile methodologies focus on the following:

Individuals and Interactions rather than processes and tools Working Solutions rather than comprehensive documentation and project plans Customer collaboration rather than contract negotiation; and Responding to change rather than following a plan.

For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors, this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.

For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.

I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.

Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.

Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.

So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.

In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.

This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.

I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.


The Business Analyst and the Cloud
by Limor Wainstein
25 Dec 2017 at 12:17pm

The age of cloud computing is now so firmly established that research firm Gartner predicted by 2020, a corporate "no-cloud" policy will be as rare as a "no-internet" policy is today. In the same press release, Gartner went on to predict that spending on compute power sold by cloud providers will exceed that of compute power sold and deployed into traditional enterprise data centers.


Given the ubiquity of cloud computing, business analysts need to prepare for the cloud and understand how it affects their roles. As valuable problem solvers within all organizations, business analysts will help to streamline and optimize business processes for deployment in the cloud. Below are five things you need to know about the cloud if you are a BA—these insights will help better prepare you for your company’s likely move to some form of cloud computing service. You’ll find out about motivations for moving to the cloud, some popular products offered by cloud vendors, such as AWS Amazon EFS, and much more.


Why Move to the Cloud?

Given its explosion in adoption over the last few years by all kinds of businesses, it’s helpful to understand the motivations behind the buzz about cloud computing.

Perhaps the most important reason for its surge in popularity is cost-efficiency. Without a cloud solution, organizations must fund data centers, servers, hard drives, network capacity, security, and infrastructural upgrades. Moving to the cloud reduces, and, in some cases eliminates many of these costs. In the cloud, you typically pay only for what you use, and infrastructural costs are much lower because there are fewer IT assets on-premises to maintain or upgrade.


The second consideration is scalability, meaning the ability of a computer application or service to handle growing workloads by adding more computing resources or upgrading existing computers. Scalability is difficult in traditional on-premise IT systems. However, in the cloud, scalability is as simple as requesting more cloud computing instances or requesting your provider to upgrade existing instances.

Cloud Computing Options

Organizations typically use three broad types of cloud service:


Software-as-a-service (SaaS). The most comprehensive option, SaaS outsources infrastructure, software, and its underlying platforms (OS, databases, etc.) all to the cloud vendor.

Platform-as-a-service (PaaS). The middle ground cloud computing option in which the vendor provides infrastructure and essential tools such as databases and operating systems. Businesses then build custom applications which run using the provided infrastructure and platform.

Infrastructure-as-a-service (IaaS). This option provides core infrastructure in the cloud while the organization manages everything else.

Cloud Vendors

A significant number of vendors provide cloud services for enterprises, and it can be tough for businesses to choose the right option for their use case. Perhaps the most well-known of these vendors is Amazon Web Services (AWS), the current market leader in cloud computing according to IDC.


AWS offers several types of cloud solution, including Amazon EFS, which provides cloud storage on Amazon EC2 cloud computers, and is commonly used for analytics, Big Data, and web serving. There is also Amazon S3, which is low cost storage typically used to distribute static web content or host static websites. To dive a little more deeply, see this post about managing Amazon EFS volumes in the cloud and how to get started with EC2.


Other options outside of AWS include Microsoft, which has IaaS, Saas, and PaaS options, and IBM Cloud.

Cloud Computing Issues

Just because cloud computing is so popular either as a hybrid solution (combining on-premises and cloud services) or as a fully-fledged cloud-only solution, this does not mean it’s without concerns.


Security

A 2012 breach of popular SaaS service Dropbox resulted in the compromise of 68 million passwords, and there have been other security breaches since. Such incidents lead to speculation about the security of cloud computing services and how cloud hackers might get access to customer data or halt mission-critical business processes.


Despite these incidents, the cloud is very secure, and most cloud vendors enforce rigid security measures including access control, encryption, and authentication.


Outages

When a business relies on cloud providers to help provide its mission-critical apps and services, any outages experienced by the cloud provider can send businesses offline too. A 2017 Amazon S3 outage caused problems for many websites, making some completely inaccessible (more details).


Businesses can combat potential outage issues by using disaster recovery services. It’s also worth noting that disasters can happen to IT centers on-premises so this is not an issue unique to the cloud.

Business Analysts and Cloud Computing

As a bridge between the problems cloud computing attempts to solve and the implementation of cloud technology, the BA has a vital role in ensuring an optimum cloud computing strategy, whether hybrid or cloud-only.


The BA helps to:


Identify which processes or services should be moved to the cloud

Outline the required governance and policies to ensure the integrity and security of sensitive organizational data

Help businesses understand the levels of service required by its cloud providers to ensure any cloud solutions achieve what businesses need from them

Indicate how best to monitor cloud performance and identify personnel responsible for this monitoring


Business analysts are the best-suited professionals at any organization to fulfill the above duties and ensure a smooth integration with cloud technology.


Conclusion

Cloud computing will provide more exciting opportunities for business analysts to flourish and use their skills to do what they do best—solve real business problems. Whether your business opts for a SaaS solution like Salesforce, or one of Amazon’s IaaS/PaaS services such as Amazon EFS or S3, the above information should ensure adequate preparation for the main concerns you’ll need to deal with as a business analyst in the age of cloud computing.


Is ETL Still Relevant?
by Limor Wainstein
29 Nov 2017 at 11:23am

The title of this article poses a pertinent question for modern enterprises that increasingly make use of powerful high-end analytic data engines, such as Hadoop clusters and cloud-based data warehouses (see this article by Forbes, which deals with similar questions).

The challenge for enterprises that use analytic engines is one of data movement—what is the best way to get data from operational systems into data warehouses and other data platforms so that it can be queried for reporting and analytics purposes?

ETL (Extract, Transform, Load) is one such method for moving data, and it is one of the oldest data movement methods. However, debate continues as to how relevant ETL still is.

Below you'll find out exactly what ETL entails, some use cases for ETL tools, and whether ETL tools are still relevant in a world where enterprises can leverage powerful modern data platforms to transform data inside those systems to be ready for use with their business-critical applications, instead of requiring a separate transformation engine.


What is ETL?

ETL (Extract, Transform, Load) is a process of moving data from source systems, transforming data in a transformation engine for use with target applications by applying a set of rules to the data (standardizing, aggregations), and finally, loading the transformed data into the target systems, which are usually data warehouses or other data repositories. The end goal of using ETL is to enable businesses to make data-driven business decisions.

Some ETL use cases and examples are:

Pulling data from different transactional systems into ODS (operational data stores) for operational reporting and decision making.  Retrieving data from transactional databases, transforming it for data warehouse use, and loading the transformed data into the data warehouse. Extracting data from XML files, structuring it, and loading to a data mart to serve a particular community of knowledge workers within organizations. What Are ETL Tools Used For?

ETL tools are used to manage the flow of data between source systems and target systems with ETL processes. Organizations can create their own ETL tools using scripts—this approach is suitable for a small number of data sources with similar types of data.

For most use cases, ETL tools created by other companies offer more functionality by implementing data transformations easily and consistently across various data sources, such as XML files and relational databases. ETL tools use transformation engines to sort, join, merge, reformat, and aggregate data.

Enterprises and organizations can avail of either commercially available ETL tools or open-source tools.

Useful ETL Tools

There are several different ETL tools on the market—here are some examples of the most useful ETL tools currently available:

Apatar—this open source ETL tool comes with a practical user interface that can reduce R&D costs. Apatar is written in Java, and organizations can use the tool to easily populate data warehouses and data marts. Scriptella is another open source ETL tool written in Java that can use SQL or any other scripting language to perform data transformations. You can work with multiple data sources ETL file in Scriptella, and the tool integrates with any integrates with any JDBC/ODBC-compliant driver. Stitch is a commercial self-servicing data pipeline that loads data into data warehouses using ETL processes. Stitch requires no API maintenance or scripting, and it can handle both bulk and incremental data updates. Fivetran is a commercially available fully managed data pipeline solution that integrates data from all your cloud services and databases into a single data warehouse using ETL processes. Camel is Apache's open source data integration framework built using Java. Camel has ETL functionality through its available libraries, which can be used to build programs that perform ETL operations. Wait a Minute. Is ETL Still Relevant?

Enterprises are increasingly leveraging cloud-based solutions for their data needs, in particular, for BI and analytics. This 2017 report found that cloud BI adoption increased in respondent companies from 29% to 43% from 2013 to 2016, and that 78 percent of organizations plan to increase their cloud use for BI and data management through 2017.

With powerful modern solutions such as cloud-based data warehouses, it's becoming more common and more practical to take an ELT approach to data movement. ELT (Extract, Load, Transform) is an alternative way of moving data from source systems to centralized data repositories without transforming the data before it's loaded into the target systems.

With ELT, all extracted raw data resides in the data warehouse, where powerful architectures can transform the data as needed to serve business needs. In other words, the transformation is performed when the analytic queries are run.

The major upside to ELT is that there is no waiting—all data is accessible at all times. This is in contrast to the traditional ETL approach to data movement, in which analysts and BI users must wait for the full ETL process to complete before accessing data.

ETL, therefore, is outdated for most use cases. Cloud infrastructure makes data more accessible than ever before, without the need to maintain complex scripts that transform the data for analytic use, as in ETL.

However, ETL still has a place in legacy data warehouses used by companies or organizations that don't plan to transition to the cloud. With the adoption of cloud-based data solutions skyrocketing, it won't be long before ETL completely loses its relevance.

Closing Thoughts All companies or organizations that want to analyse their data to make business decisions are faced with a common challenge—how to move data from source systems, such as transactional databases, to the target systems used for data analysis and BI. ETL provides one way of moving data by pulling it from source systems, shaping it to be ready for use with analytic applications, and finally loading the data to the target systems. There are several open source and commercial ETL tools available that can make the ETL process more functional and practical. However, the transition to cloud-based data solutions makes ETL processes less relevant, because there is no need to transform data before it moves to the warehouse or other analytic repository—cloud infrastructures have the resources to efficiently transform raw data as it is needed. ETL is outdated, but it's still useful for legacy data warehouses used by companies that don't plan to move to the cloud or don't foresee much future data growth.

 


Business Transformation, the importance of understanding your current state.
by EA Learning
31 Oct 2017 at 7:39pm

I recently walked into a large shopping centre on a mission to buy a christening present for a friends son. I was very clear on what I wanted I just needed to find it… I was on my lunch break so I need to get the job done as I had a meeting that I needed to attend back in the office straight after lunch!

I am not a frequent shopper and to be honest I find the crowds and the volume of options at shopping centre’s both distracting and stressful. After walking in from the street the first thing I did was look for a map to show me where I needed to go. I quickly found the map and the section that I needed which was on the 4th floor. There was a big red arrow on the map saying You Are Here. The problem was I wasn’t a 100% sure where You Are Here was, in relation to where I wanted to get to on the 4th floor!

I knew that I had to get to the fourth floor, but was I on the ground floor or the first floor, and where were the escalators and elevators that I needed to find? When I looked at the map again it dawned on me that I wasn’t even sure as which way I was facing. Given that was time constrained my anxiety and I needed to get this job done my anxiety levels started to rise. Should I Just start walking to where I think the escalators and/ or elevators were, or should I take a couple of minutes to orientate myself?

I did a quick environmental scan and identified a couple of the nearby shops which allowed me to determine which floor I was on. I then found the entrance that I had come in from on the map which allowed me to orientate myself. The easiest option was to take the escalator, as they were closest. I had a clear map in my head of where I was, where I needed to go, how I was going to get there and what I was going to do when I arrived. My anxiety levels immediately decreased as I felt confident that I would be able to get the job done and be back in the office before my next meeting.

The key piece of information that facilitated the whole thing was I knew where I was starting from. To use Business Architecture parlance, I understood my current state!

Whenever you are setting off on a journey be it a trip to the shops, an overseas holiday, a journey of personal discovery or a process to Transform an organisation one of the key determinants of success is knowing where you are starting from. While it sounds simple in practice it is one of the most difficult tasks in the Business Transformation process.

When you speak with stakeholders within an organisation undergoing Transformation about the current organisational state you will often get as many views as there are business functions within the organisation. Often to the point that there is often not even agreement on what Business Model the organisation utilises or even what business they are in.

The interesting paradigm is that while most people can’t agree on where they are, there is often clear agreement on where they want to be! In most cases, the board has set a clear strategy which has been codified into the annual business plan and presented to management. The goals and objectives detailed in the business plan are aspirational, without a detailed understanding by the executive of what the organisations' current capabilities are, and it is the role of management to figure out how to deliver them.

Management identifies initiatives required to achieve the business plan, goals and objectives and allocates budgets. The initiatives are usually developed based on functional responsibilities and often in isolation to the rest of the business. Management then starts executing on the Transformation initiatives, and this where the wheels often fall off the Transformation process.

The main reason for this is that there is no clear plan or blueprint to define the organisations' current state to connect the business plan to the Programme of Transformation initiatives. There is no Business Architecture to clearly direct people on their journey, and in many cases, people aren’t 100% sure what specifically needs to change. They just know that there are goals set out for them in the business plan and they need to meet them.

What ensues is a lot of activity and consumption of resources without many tangible outcomes.

In most cases, Transformation teams are clear on the Target Operating Model (TOM) that they want to achieve but they are not able to clearly define their current operating model and consequently, do not know what the most efficient and effective way is to achieve the TOM. Every year in Australia millions of dollars are spent on Business Transformation initiatives that do not deliver any demonstrable business improvement and one of the fundamental reasons for this is that organisations set off on their transformation journeys without a sufficient understanding of where they currently are.

A quick postscript to my shopping journey. I made it to the 4th floor without too many distractions. When I got there I couldn’t find what I was looking for, but luckily as I was in the right area for Christening presents I found an alternative that was better and returned to the office in time for my next meeting. If only all journeys were so simple.

If you are interested in our Business Transformation training, please contact us for more information on how we can assist. Click here to view our course range and to send through an enquire or email info@ealearning.com

Written by Scott Comte, General Manager EA Learning 


UX Canvas
by BusinessAnalysisHub
26 Oct 2017 at 1:25pm

Have you woken up in the middle of night thinking how am I going to steer my team, give them the direction that they need but at the same time not constraint in what they want to build/deliver. I recently went through one of these night- I have joined an interesting project where we have very tight timescale to deliver a tech product to operational staff. When, I say tight we are talking about the end product had to be delivered within 100 days.

We had recently finished the discovery stage of the project, this had been very frantic and time pressured led- we only had three weeks to do our discovery. This naturally resulted in the team not having the opportunity to speak and consolidate their findings with each other.

As, the lead business analyst on the project, it was my role on the project to make sure that we had the best picture of what the current ‘As is’ situation was like on the ground. It is also my role to make sure that we have got access to the policy and legal requirements that we had to work within.

It was when we were heading rapidly towards the end of Discovery that I came to the realization that we had access to lots of information and ideas within the team. We needed some place where we could come together to discuss our findings and learning with each other.

I learnt about Lean UX Canvas from this Jeff Gothelf blog that I happened to stumble across. I have always been a big fan of Jeff Gothelf especially his book ‘Sense and Respond’, so naturally I was curious about this canvas.

I have used product canvas, business model canvas and opportunity canvas with the team but this was first time I had come across UX lean canvas. I was drawn to the canvas, as it had everything that we needed as the team — user benefits/ riskiest assumptions

For me this was a perfect tool, as it allowed everyone to contribute their findings into this one artefact, that we as the team could reference back to. Once, I decided I was going with this tool, I introduced it to the team, whom seemed to be onboard with trying it out.

The best way to complete the canvas for me was to get the team together in the collaboration space and start having the conversation around the different components within the canvas. We decided the core area we needed to agree first was ‘what was the business problem that we are trying to solve’.

Once, we agreed then we could then tackle what ‘Solution ideas’ that our products need to have. I must admit this is one that caused us the most discussion in the team- as the user researcher thought the solution should cover certain things while the service manager was not necessarily in agreement. However, by having these discussions we were able to expose areas that we still needed information on, or where we had gaps in knowledge in the team.

We then, went around the canvas completing the different blocks within it. It took the team about a day to complete the canvas — which I think is ideal time period to do something like this.

I would definitely recommend utilizing this tool with your team, it is a great way to bring all the professions together to get them discuss their findings. It, is also a great tool to generate conversation around the product that you are developing as a team.

My other tip for doing a Lean UX Canvas is that it does not have to be perfect, don’t spend time trying to make it look pretty- we completed ours on brown paper that we took a photo of. This tool is not about a prefect artefact but instead it’s about making sure that as the team you can all agree what is the problem you are trying to solve, the hypothesis that you want to test and the riskiest assumption that you want to test first.



When is Security not a Non Functional Requirement?
by Peter
22 Aug 2017 at 1:12pm

If you are building a reusable Security Product tool to specifically address Security Technical Implementation Guide (STIG)  Findings, should the requirements be considered Non Functional Requirements or Functional Requirements?

For example if there are a number of STIGs such as:

The minimum password length shall be 15 characters The maximum password length shall be 30 characters The password shall contain at least one of each of the following types of characters Numeric Character Uppercase Alphabetic Character Lowercase Alphabetic Character Special Character (!,@,#, etc.) The password shall be changed a maximum of every 60 days

 should I add them to the Functional or Non Functional section of my Requirements Document.

Add your answers and thoughts in comments below:


5 Business Problems You Can Solve Using SQL Temporal Tables
by Bert Wagner
11 Jul 2017 at 6:08am

It’s 4:30 pm on Friday and Mr. Manager comes along to tell you that he needs you to run some important ad-hoc analysis for him.

Previously this meant having to stay late at the office, writing cumbersome queries to extract business information from transactional data.

Lucky for you, you’ve recently started using Temporal Tables in SQL Server ensuring that you’ll be able to answer your boss’s questions and still make it to happy hour for $3 margaritas.

Sound like a plan? Keep reading below!

The Data

For these demos, we’ll be using my imaginary car rental business data. It consists of our temporal table dbo.CarInventory and our history table dbo.CarInventoryHistory:

I’ve upgraded my business — we now have FOUR Chevy Malibus available for you to rent Business Problem #1 — “Get me current inventory!”

To get our current inventory of rental cars, all we have to do is query the temporal table:

SELECT * FROM dbo.CarInventory

That’s it.

I know this query seems lame — it’s just a SELECT FROM statement. There are no FOR SYSTEM TIME clauses, WHERE statements, and no other interesting T-SQL features.

But that’s the point! Have you ever had to get the “current” rows out of a table that is keeping track of all transactions? I’m sure it involved some GROUP BY statements, some window functions, and more than a few cups of coffee.

Temporal tables automatically manage your transaction history, providing the most current records in one table (dbo.CarInventory) and all of the historical transactions in another (dbo.CarInventoryHistory). No need for complicated queries.

Business Problem #2 — “How many miles on average do our customers drive each of our cars?”

In this example, we use FOR SYSTEM_TIME ALL and a plain old GROUP BY to get the data we need:

SELECT
CarId, AVG(Mileage) AS AverageMileage
FROM
dbo.CarInventory FOR SYSTEM_TIME ALL
WHERE
InLot = 1 -- The car has been successfully returned to our lot
AND SysStartTime > '2017-05-13 08:00:00.0000000' -- Ignore our initial car purchase
GROUP BY
CarId Some cars get driven a lot more. Causation or correlation?

FOR SYSTEM_TIME ALL returns all rows from both the temporal and history table. It’s equivalent to:

SELECT * FROM dbo.CarInventory
UNION ALL
SELECT * FROM dbo.CarInventoryHistory

Once again, there isn’t anything too fancy going on here — but that’s the point. With temporal tables, your data is organized to make analysis easier.

Business Problem #3 — “How many cars do we rent out week over week?”

Here at Wagner Car Rentals we want to figure out how often our cars are being rented and see how those numbers change from week to week.

SELECT
CurrentWeek.CarId,
CurrentWeek.RentalCount AS CurrentRentalCount,
PreviousWeek.RentalCount AS PreviousRentalCount
FROM
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-06-05' TO '2017-06-12'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) CurrentWeek
FULL JOIN
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-05-29' TO '2017-06-05'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) PreviousWeek
ON CurrentWeek.CarId = PreviousWeek.CarId

In this query, we are using FOR SYSTEM_TIME FOR/TO on our temporal table to specify what data we want in our “CurrentWeek” and “PreviousWeek” subqueries.

FOR/TO returns any records that were active during the specified range(BETWEEN/AND does the same thing, but its upper bound datetime2 value is inclusive instead of exclusive).

Business Problem #4 — “What color cars are rented most often?”

We’re thinking of expanding our fleet of rental vehicles and want to purchase cars in the most popular colors so we can keep customers happy (and get more of their business!). How can we tell which color cars get rented most often?

SELECT
CarId,
Color,
COUNT(*)/2 AS RentalCount -- Divide by 2 because transactions are double counted (rental and return dates)
FROM
dbo.CarInventory FOR SYSTEM_TIME CONTAINED IN ('2017-05-15','2017-06-15')
GROUP BY
CarId,
Color

Here we use CONTAINED IN because we want to get precise counts of how many cars were rented and returned in a specific date range (if a car wasn’t returned — stolen, wrecked and totaled, etc… — we don’t want to purchase more of those colors in the future).

Business Problem #5 — “Jerry broke it. FIX IT!”

The computer systems that we use at Wagner Car Rentals are a little…dated.

Instead of scanning a bar code to return a car back into our system, our employees need to manually type in the car details. The problem here is that some employees (like Jerry) can’t type, and often makes typos:

SELECT * FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4

Having inconsistent data makes our reporting much more difficult, but fortunately since we have our temporal table tracking row-level history, we can easily correct Jerry’s typos by pulling the correct values from a previous record:

;WITH InventoryHistory
AS
(
SELECT ROW_NUMBER () OVER (PARTITION BY CarId ORDER BY SysStartTime DESC) AS RN, *
FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4
)
--SELECT * FROM InventoryHistory
/*Update current row by using N-th row version from history (default is 1 - i.e. last version)*/
UPDATE dbo.CarInventory
SET Color = h.Color
FROM
dbo.CarInventory i
INNER JOIN InventoryHistory h
ON i.CarId = h.CarId
AND RN = 2 Typos fixed!

Although we could have fixed this issue without using a temporal table, it shows how having all of the row-level transaction history makes it possible to repair incorrect data in more difficult scenarios. For even hairier situations, you can even roll-back your temporal table data.

Conclusion

Temporal tables are easy to setup and make writing analytical queries a cinch.

Hopefully writing queries against temporal tables will prevent you from having to stay late in the office the next time your manager asks you to run some ad-hoc analysis.

-----

Bert Wagner

https://blog.bertwagner.com


A New Metaphor for Business Analysis
by Ronak Sanghavi
25 Jun 2017 at 12:29pm
Current State

For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how it is described. So does that mean we should ignore this debate? I don’t think so. A metaphor is a powerful tool to develop useful mental models, and efficiently create possibilities for value-creation.

My take on this debate is that both sides are right. This is so, because the state of business analysis is not uniformly mature across countries and work cultures. For instance, BAs in North America are more likely to find the “Bridge” metaphor limiting/restrictive because of how the role has matured in the past decades. On the other side, for most BAs in emerging economies the “Bridge” metaphor still provides aspirational value.

So, what is behind my ambivalence? Most common interpretation of the metaphor is that it connects business and IT stakeholders. My take is that it is a bridge between the problem domain (current state) and the solution domain (future state). This take on the “Bridge” metaphor is not limiting, because it includes all levels of business analysis maturity - from strategy analysis to solution evaluation, and everything in between.

A New Metaphor

Not that there is anything wrong with a debate, but it is time for a new metaphor. I would like to share with the BA community a metaphor which has shaped my business analysis journey, especially in the past 5 years since I co-founded a business analysis startup. I look at business analysis as a “GPS” to move from the current state to the desired state. In other words, it guides stakeholders to achieve project success and organization goals. This metaphor is more inclusive (represents all flavors of BA role) and accurate (represents full potential of the discipline).

Let us look at the elements (features) of the conventional GPS system, which make it so useful; and how business analysis aligns with them.


#

GPS Feature

How Business Analysis aligns with GPS Feature in Projects

0

MAP – a useful representation of the landscape

· Build a representation of the business and IT landscape through research and analysis of industry; market forces, including competition; organization; operations; and current IT systems

1

CURRENT LOCATION – ability to determine current location in the context of the MAP

· Provide appropriate context for a project by customizing and sharing with stakeholders the relevant business and IT landscape

· Define current state of the problem domain, and frame the problem statement

2

DESTINATION – assistance to select destination, e.g. a highly rated Point of Interest

· Help organizations prioritize IT investments through business cases

· Facilitate definition of the desired state through solution scope and requirements specifications

3

NAVIGATION – real-time navigation to help reach destination most efficiently

· Facilitate selection of the best solution to meet requirements

· Facilitate shared understanding of requirements through requirements transition, continuous communication, traceability and change management

· Identify, engage, collaborate and coordinate with stakeholders; and support them to achieve desired solution

 

Any single feature, from the list above, is useful by itself. The “GPS” metaphor on business analysis is inclusive and aspirational enough regardless of the maturity of the BA role in a country, work culture, organization, or even an individual project. Furthermore, by symbolizing the positive global impact GPS has had on humanity, this metaphor helps us quickly and robustly communicate the power and value of the business analysis discipline.

My Experiments with this Metaphor

The “GPS” metaphor is not just a concept, which I made up for the purpose of writing this article. This mental model has fueled my passion, and shaped how I have approached business analysis in the latter part of my career. In fact, all service and solution offerings of my company are built on this mental model. I have received favorable and instant acceptance of this metaphor every time I have pitched my company’s solution portfolio to potential clients. I have also received positive feedback in training and coaching interactions from individuals when I have used this metaphor to provide more clarity about business analysis.

Your turn

I would love to hear your views on this. I hope that your active and constructive participation in this dialogue will not only help me crystallize my thoughts on this topic, but also give the BA community a new metaphor to actuate and communicate the potential of our profession.



What is Pega Process Managment?
by SarikaA
29 May 2017 at 3:50am

Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”.

Pega systems has been at the forefront of rules-based business automation systems since the early 1980s, a natural outgrowth of our founder’s pioneering work in computerized chess play. In recent years, as more and more businesses have concluded that business process management suites are a “must-have” technology, our BPM business has grown at twice the rate of the overall BPM market. At the same time, major analysts like Forrester and Gartner have consistently rated Pega systems as the leader in the dynamic BPM sector.

Pegasystems knows that what it all comes down to is delivering real-world business benefits, efficiently and quickly:

More so than any other process management suite, Pega BPM puts business users in control of process design and creation, while automating most of the code development and minimizing reliance on technologists.

Pega BPM patented inheritance technology enables a multi-layered process model in which a base of enterprise-wide rules and procedures are dynamically merged with an overlay of context-specific refinements suitable to particular regions, product lines, channels, or customers. This model enables you to capture in your BPM services a real-world reflecting mix of the universal and the particular.

To speed your time-to-benefits, Pega BPM offers a full range of industry-specific solution frameworks, based on best practices in financial services, insurance, health care, telecommunications, government, and others. For business process outsourcers, we also offer tailored BPO software and BPO solutions.

The perfect platform for enterprise-scale business performance management or business process integration initiatives as well as for more narrowly targeted pilot programs, the Pega business process management suite empowers business users, accommodates real-world variety, and pays rapid dividends.

End-to-End Business Process Management Services

Pegasystems delivers expert business process management services to support all phases and facets of your BPM project:

-Design review — Pegasystems’ business process management services team can help you get your BPM project off on the right foot with a thorough review of your application design. Working side-by-side with your project team and leveraging best-practice design principles, Pega BPM services staff will provide valuable feedback on both your design and your design process.

-Usability review — No matter how well-designed an application is internally, and no matter how powerful the underlying business process management system, the application won’t live up to its potential if your user interfaces are not meeting the needs of end users. The Pega business process management services team will review your UIs from the user perspective and help you identify ways to improve the user experience and increase user productivity.

-Transition readiness — Before you launch, Pega business process management services professionals will help you test your application, tune it, and prepare it for deployment. We’ll also work with you to assess your organization’s readiness to utilize the application.

-Performance check-up — Once your BPM application has been up and running for six months to a year, Pega professional services can evaluate your application’s performance to see whether you’re getting your maximum possible return. Detailed analysis and feedback from Pega business process management services -personnel can help you to fine tune your application and to optimize future applications as well.

-BPM methodology coaching — Pegasystems veteran BPM experts can coach your team on all the nuances of implementing an iterative and agile BPM methodology that best leverages the robust capabilities of your Pega BPM platform.

-Centers of excellence creation — Many leading companies are creating BPM-focused Centers of Excellence to drive BPM implementations across the enterprise. Pega professional services can help you with all aspects of launching a BPM Center of Excellence, including strategy development, infrastructure creation, and building of a BPM knowledge base.



Newsfeed display by CaRP
Share this page


Follow Business Analysts