News for the Business Analyst and Systems Analyst


Why Every Job Seeker Should Have a Personal Website, And What It Should Include

$1.95 Web.com Site Builder

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

Requirements traceability : What, why and how
Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated. This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

Satisfy

Relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

Requirement

To list products in the ecommerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Store front end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

About me
I am a professional BA, trainer, coach and author.

If you like my posts please like/share/comment and spread the word in your network.

Would love to connect with fellow professionals.

You can also reach me at LN@AdaptiveUS.com

About my organization, Adaptive US
We provide training, study guides, question banks, necessary PDUs for ECBA, CCBA, CBAP certifications.

For more details, please visit www.AdaptiveUS.com


Business Analysis Career Path
Most IT jobs have a clear, specific job description and career path. However, the business analyst career path tends to vary, as do the descriptions from job to job. The business analyst career path is best. Because, “There are career tracks that zigzag back and forth between IT and business. Someone might start as a business analyst, and then move into a project management job, then an IT management path, and then go back to an innovation path ... then to process management, then move up a rung to process leadership or process ownership, and then go back over to management as manager of an IT line of business."

Today’s Business Analyst

The 21st century business analyst’s world is multifaceted. As a mediator, moderator, connector and ambassador, the business analyst must bring the business needs together with IT resources. Successful business analysts tend to be clear communicators, smooth facilitators, precise analyzers and team players. Plus, the ideal analyst has the versatility of various business functions, such as operations, finance, engineering, technology or architecture. Business analyst role is fuzzy at many companies. These jobs usually describe what a BA does by telling people I am a bridge between business systems from the end user to functional implementation of technical solutions. But when you tell somebody that they look at you like ’OK, what do you really do?’"

What Does a Business Analyst Do?

As you explore the business analyst career path, you’ll need to clear up the confusion and learn about the many hats business analysts wear. From being a good communicator and data analyzer to possessing project management and technical skills, business analysts regularly use a variety of techniques. They are the bridge that fills in the gap between each department throughout every step of development. Modern Analyst identifies several characteristics that make up the role of a business analyst as follows:

  • The analyst works with the business to identify opportunities for improvement in business operations and processes

  • The analyst is involved in the design or modification of business systems or IT systems

  • The analyst interacts with the business stakeholders and subject matter experts in order to understand their problems and needs

  • The analyst gathers, documents, and analyzes business needs and requirements

  • The analyst solves business problems and, as needed, designs technical solutions

  • The analyst documents the functional and, sometimes, technical design of the system

  • The analyst interacts with system architects and developers to ensure the system is properly implemented

  • The analyst may help test the system and create system documentation and user manuals

Starting Your Career as a Business Analyst

Beginning business analysts need to have either a strong business background or extensive IT knowledge. With that, you can start to work as a business analyst with job responsibilities that include collecting, analyzing, communicating and documenting requirements, user-testing and so on. Entry-level jobs may include industry/domain expert, developer, and/or quality assurance. Within a few years you could choose to become a Subject Matter Expert (SME). This is the time to delve into the areas that interest you most and develop those areas that can help you progress into higher management positions.

Moving Up the Ladder

Once you have several years of experience in the industry, you will reach a pivotal turning point where you can choose the next step in your business analyst career. After three to five years, you can be positioned to move up into roles such as IT business analyst, senior/lead business analyst or product manager. The more experience you have as a business analyst, the more likely you are to be assigned larger and/or more complex projects. After eight to 10 years in various business analysis positions, you can advance to chief technology officer or work as a consultant. You can take the business analyst career path as far as you would like, progressing through management levels as far as your expertise, talents and desires take you.

How Much Do Business Analysts Make?

Depending upon which business analyst career path you choose, you’re certain to benefit from a highly rewarding and lucrative career. To give you an idea of how profitable this field can be, take a look at these job titles and average salaries, based on U.S. Bureau of Labor Statistics, for a variety of business analyst jobs:

Job Title

Average Annual Salary

Information Security Analyst

$92,600

Computer Systems Analyst

87,220

Management Analyst

$81,330

Financial Analyst

$81,760

Budget Analyst

$73,840




What is Predictive Analytics and Why Does It Matter?

What is Data Analytics?

To understand the meaning of Predictive Analytics, let’s describe what Data is first. Data is a collection of facts, information, and observations related to a context. The data can be either structured or unstructured, stored in databases, spreadsheets, files, etc. Data analytics is the science of examining the data to drive conclusions and find answers to particular questions.

Data Analytics can be defined and applied at different levels:

Predictive Analytics of Gartner


As the above Gartner diagram shows, we can define four levels of analytics:

  1. Descriptive tells us “What happened?” which is pretty much all of the standard reporting capabilities that we have seen so far in any computerized system. For example, a sales report generated for a customer to understand the transactions for the current year.
  2. Diagnostic tells us “Why did it happen?” by using advanced techniques such as drill-down, data discovery, data mining and correlations (e.g., BI finds the relationship between data points and helps us to understand Why a specific event has occurred).
  3. Predictive tells us “What will happen?” by using historical data and an understanding of the past in order to predict the future. This is called supervised learning in AI.
  4. Prescriptive tells us “What should I do?” based on the information that we could predict using “Predictive” analytics. The system can prescribe the best next action, offer, decision, etc., to the user or it can fully automate the cycle (when possible)

Let’s see what is so special about Predictive Analytics and how it can help your business.

What is Predictive Analytics? Why does it matter?

Data Analytics nowadays is a hot topic, especially with the advancement of AI and accessibility of fast and cheap computing power. Predictive Analytics is a special branch of AI that uses supervised learning, statistical techniques from predictive modelling, machine learning, and data mining to analyze current and historical data in order to make predictions about the future. Predictive Analytics can play a big role in helping you to win the competition.

How? Predictive Analytics can harness the data and create a unique opportunity for organizations.

Real Life Examples

Below are just a few scenarios in which you can use Predictive Analytics to find a new opportunity and take action on it:

  • Forecasting sales volume based on last year’s sales history of a product and current orders to ensure you will have always have the right amount of the item in stock. Potentially, you can use a Workflow to automate the whole approval-buy cycle of the purchase.
  • Finding the probability of a patient illness based on the history of similar patients in the medical center during the current season, and helping the GP to identify and diagnose illnesses based on the probability of these hypotheses. Potentially, you can use Decision Automation to prescribe the right set of activities, drugs, and regimens for the patients.
  • Classifying customers based on buying habits, and sending the right offer to the right customer to boost sales. Potentially, you can automate the entire cycle and let the system send out vouchers, sales offers, etc., using the right groups of products to the correct sets of customers. Then the system monitors the customers behavior again and feeds the results back to the model. This improves the quality of the next offer in order to maximize profitability.

Conclusion

It is important to understand that the value of Predictive Analytics has become a reality. However, it will have positive impact on our day-to-day jobs only if we utilize them and close the loop of the Observe-Orient-Decide-Act (OODA), not just show these on a beautiful dashboard.

These are just few examples and in the next post I will show you how to build a predictive model using FlexRule.



Big Bucket of Rules
There are many definition of business rules and the one that I really like is that business rules are:

Criterion used to:

  • Guide conduct or actions.
  • Shape judgments of behavior.
  • Make decisions.

Ronald Ross

 

Having this definition in mind, let’s see what challenges a traditional rules management system will face when you are trying to scale. By “scaling” we do not mean the execution time in this context. I will elaborate further on that in this article.

Traditional Approach – Business Rules Oriented

In any traditional Business Rules Management System (BRMS) there is an authoring environment (i.e., a rule editor), that allows users start writing business rules. The interface presents a business rule in a few different ways, such as if-then-else statements, graphical tree, etc. You can then do things like group, tag, and label these rules for one good reason – to be able to find them. That’s because when your rule systems grow to hundreds of thousands of rules, you will feel the pain.

  • You need to find and group the business rules to be able to add them in a set (i.e. ruleset) for execution.
  • You need to be able to understand if any business rules are duplicated, or if you already have a variation of a particular rule
  • You need to be able to understand the potential impact if you decide to change a business rule

With this traditional approach, the reusable part of the system are the actual business rules.

Big Bucket of Rules

As a first impression, reusable business rules sound appealing. However, this conveniently innocent idea will introduce many challenges down the track. In a real system, we are talking about tens, if not hundreds of thousands of business rules all collaborating with each other to deliver value and determine an outcome.

Finding one business rule in that repository is like finding needle in a haystack! No matter how well you tag, label, group, or name each one, it is going to be hard (even nearly impossible) finding them in the repository, let alone changing a couple of them and determining the impact.
Why is this the case? Well, remember the idea of reusable business rules that we were advocating? Now you need to ensure that any change makes sense for all the other parts on which the business rules rely.

Individual business rules are very important, but often so small and granular that their reusability is of little or no value!

big bucket of rules


 

The picture shown above is pretty much akin to your enterprise business rules repository. Where is the piece you wanted? You also attempted to label and tag them to be found more easily when required.

Alternative – Business Decisions Oriented

Although individual business rules are important, what is more important is their ability to collaborate in order to achieve an outcome. We are more interested in the outcome – that’s why we tried to group the business rules together in the first place to achieve a desired, relevant outcome that makes business sense.

The outcomes we are after are tightly coupled to a set of Business Decisions. Consider the challenge you are trying to tackle this perspective – what business decisions are you trying to make?
When you think about it that way, your life becomes easier, simply because this question will elevate the granularity of the rules. Don’t worry about the individual business rules too soon. You need to manage the decisions rather than the business rules. The business decision becomes the module of reusability, regardless of the underlying implementation.

These business decisions are just not another type of rule sets! They are fundamentally different from mindset, approach, modeling, etc. We are going to examine business decisions in future posts in more detail.

Conclusion

If you don’t think about “business rules” in the context of the problem you are trying to solve and address, then you will not need many of things that traditional Business Rules Management Systems (BRMS) offer in the first place (e.g., Finding an orphan business rule). Traditional business rules management systems (BRMS) need those capabilities because the approach to rules are so granular and hard to manage. Think of business decisions next time and you will not find yourself in what we refer to as a ‘Big Bucket of Rules’ problem!

The Business Decisions approach has so many direct and indirect benefits like transparency of business decisions, scalability of business rules, ease of reusability and etc. These are all promises business rules management systems were not able to deliver because of their approach to rules. 

** picture of the LEGO from https://www.flickr.com/photos/alanar/4444710186/in/photostream/




Patient diagnosis using Predictive Analytics

Patient diagnosis using Predictive Analytics

In previous post we discussed different levels of Analytics, here we show a practical example of Predictive Analytics. What if Doctors and Patients could not just get a second opinion, but a third and fourth, and fifth, and so on? We believe that our doctors are all medical experts but patient diagnosis using Predictive Analytics can help them to make more informed decisions based on current and historical data.

“Misdiagnosis accounts for about one-third of all medical error. Autopsy studies show that doctors seriously misdiagnose fatal illnesses about 20 percent of the time. “If you look at settled malpractice claims,” Britto said, “diagnosis error is about twice or three times as common as prescription error”.

Ian Ayres; Super Crunchers, How anything can be predicted, page 97

As explained by Ian Ayres, the Doctor’s diagnosis phase by doctors is the most important step in defining the patient’s journey based on the individual patient’s symptoms. When Predictive Analytics are involved in this decision, then additional historical data of similar patient’s symptoms would help the doctors to make more insightful decisions.
In the latest version of FlexRule, we added a new sample project called patient diagnosis using Predictive Analytics. This project demonstrates how a patient’s history at the same medical centre (city area) in a particular time frame would help doctors to make an informed decision for a new patient with a similar list of current symptoms.

The model has three main steps: read historical data, use the Naive Bayes (NB) algorithm to train the model, and, of course, predict the diagnosis.

Patient diagnosis using Predictive Analytics

Reading Patients History

The patient observation dataset has been read from a DataSheet (.CSV file). The dataset contains 20 patients with different symptoms and final diagnoses confirmed by their doctors and through lab tests. For example, the first row, which is patient one, had symptoms like sneezing and a sore throat and therefore was diagnosed with cold.  The second row, which is patient two, had symptoms like fatigue, stuffy nose and sneezing, which was also found to be a cold.

Patient diagnosis using Predictive Analytics

Building a Trained Model

In the second step, we train (or reload an existing) predictive model using the Naive Bayes algorithm (NB), which is one of the scalable classification algorithms for these types of dataset. This algorithm has been successfully applied to many medical problems with large amounts of data and features. Now our model is ready to predict the diagnosis for the next patient based on his current symptoms.

Predicting a New Situation

In this step we pass the data of our new patient’s current symptoms to the predictive model. Patient 21 has not been diagnosed by a doctor yet and he has stuffy nose, sneezing, and sore throat:

{
   
"Fatigue": null,
   
"Stuffy Nose": "T",
   
"Sneezing": "T",
   
"Sore Throat": "T"
}

Based on historical data and the current patient’s symptoms, our predictive model calculates the percentage probability of each disease as shown below:

Patient diagnosis using Predictive Analytics

 

Conclusion

As the result clearly shows, patient 21 is likely to have a cold with a probability of 74.81%.
The probability of a flu and allergies are 8.76% and 16.41% respectively, which are much lower than the probability of the patient having a cold.
This is a simple example, but it shows how FlexRule and predictive modelling can help a doctor make better quality patient diagnosis.


How Business Architecture can help Project Managers to be successful.

One of my favourite questions to ask candidates when I was in the executive recruitment game was “In your experience what makes a successful (insert name of role I was recruiting for)”.

It was a great catch-all question as the answers provided gave a very good indication of where the candidate sat on the professional continuum for the role in terms of experience, knowledge and competence. It also served as a good way to educate the recruiter on the varied aspects of the role. One of the key insights that I discovered through this practice was how much different professions have evolved over time. No more so than the role of Project Manager.

The Project Management profession is in growth mode. Research by the Project Management Institute (PMI) indicates that the number of roles globally will grow by 33% in the next 10 years with forecasts that there will be 88 million people working in a Project Management related role by 2027. In the research the head of the PMI in China, Bob Chen described the evolving role of Project Management in the following terms:

“As the business environment today is becoming increasingly complex and fast-changing, it has brought higher requirements to project managers. Project managers today should not only have a firm grasp of basic project management knowledge but also possess strong leadership, including skills in conflicts resolution, negotiation, stakeholder management as well as capabilities in strategic and business management,”

Breaking this down further Moira Alexander in CIO Magazine identified six key traits that differentiated good projects managers from the rest of the pack.

  1. Be a strategic business partner – be able to clearly evidence how your project is contributing to the organisations strategic goals.
  2. Encourage and recognise valuable contributions – leverage the benefits of collaboration
  3. Respect and motivate stakeholders – this particularly important when dealing with project sponsors and business stakeholders.
  4. Be fully invested in success – own the project outcome.
  5. Stress integrity and accountability
  6. Work in the grey – effectively deal with the ambiguity and complexity that is the modern business environment.

Historically it used to be that you were either a technical e.g. Information Technology (IT) Project Manager or a Business Project Manager. The traditional IT Project Manager was responsible for the delivery, planning, organizing and delegating responsibility for the completion of specific information technology outcomes.  In contrast, the  Business Project Manager delivered operating model projects with little or no technology.  Where there were technology changes they ensured that IT systems met the business requirements of users/ stakeholders and the system and operating model changes were successfully adopted to achieve business benefits.

While these are very simplistic definitions it clearly evidences that there were distinctly different skillsets required to deliver on each of these roles. Technical Project Managers came from technical backgrounds such as development, infrastructure, or engineering and they had strong technical knowledge of how a system or product should be built. The Business Project Manager would most likely came from a functional role within the business from areas such as marketing, operations or finance.  Each type of project manager’s knowledge was informed by their business experience,  training and development. They would often cross-skill on projects and may have developed broader professional knowledge through additional studies such as an MBA, but fundamentally they were a product of their functional experience. Over the last 20 years these two distinct project management professions have been slowly morphing into what we know today we know as a Project Manager.

I believe too often project managers have been forced to work with unnecessary ambiguity and complexity. This is due to the inability to clearly align their project outcomes to the strategic objectives of the organisation. This is something that you don’t develop through either business functional or technical experience and is an attribute that both Moira Alexander and Bob Chen clearly see as a key competency to being a successful project manager. It is interesting to note that they believe the key to successful project management is to not only have the ability to align your project with strategic outcomes but also to be able to communicate effectively to your stakeholders how you are supporting them to deliver strategic outcomes! This is supported by PMI research that has shown that one of the key contributors to project success rates is the level of engagement of executive sponsors. If Project Managers can effectively engage and motivate these stakeholders their ability to succeed will be greater.

Formal Project Management development pathways such as Prince 2  and Project Managers Body of Knowledge (PMBOK ) provide excellent methods to execute a project while bodies of knowledge such as Business Analysis Body of Knowledge (Babok ) provide excellent insights and tools to assist with requirements gathering. But to link project outputs to strategic objectives I think that we need to draw on the skills and knowledge of a different profession, Business Architecture.

Business Architecture, through the technique of Capability Based Management, allows a Project Manager through business-led collaboration to translate the organisations strategic objectives to project level outcomes. This is done by defining the Business Model and Value Streams required to deliver those objectives and then further breaking these down into the different capabilities (people, process, technology and data) that the outcomes of the project will enhance or establish. The artefacts and tools used to do this can be used to provide a level of traceability that the Project Manager can use to show how their business case clearly aligns what is proposed at the project level to what is important to executive stakeholders. In addition, it can support the motivation of project teams as individual team members can see how their contribution adds value to the bigger picture.

Business Architecture assists project managers and their collaborative teams to be fully invested in success and accountable (owning the project outcomes). When a project output can be traced to the establishment of or improvement in a capability (s) that has a demonstrable impact on a value stream then this will motivate business stakeholders. The tools of Business Architecture such as the Business Motivation Model, Business Model Canvas, Value Stream Maps and Capability Maturity Roadmaps are excellent ways of communicating complex project activities to executive stakeholders.

These techniques, tools and artefacts are equally effective at providing a supporting framework for project team members as they can align their value-adding activities to specific areas of capability improvement. I believe that having access to these types of frameworks will become increasingly important to Project Managers as the adoption of Agile practices increase. One of the core principles of Agile is to be continuously delivering value. In many organisations what constitutes value can be quite subjective when looked at from a Project versus Business perspective. Having a defined business architecture allows Agile Project Teams to map the outcomes of their iterations to capabilities and value streams and consequently strategic objectives. Through this mechanism, Agile Project Teams can clearly communicate to their stakeholders how their activities are adding value.

I started this piece by asking the question what makes a successful project manager. The answer, while somewhat self-evident, is someone who delivers the outcomes the organisation wants/ needs. It is how these outcomes are defined that has had the most impact on the development of the project management profession. Historically success used to be delivery of projects on time, on budget and meeting quality requirements within the defined scope. Now the requirement is to deliver demonstrable business outcomes. This has thrown up new challenges for Project Managers as they need to be able to provide their business stakeholders, particularly executives, with the confidence that they not only understand what business outcomes need to be achieved but also communicate how they are going to deliver these outcomes. This ability to link business strategy to project execution is one of the greatest benefits of Business Architecture and I believe that Project Managers who can draw on these techniques, tools and methods will position themselves as a strategic business partner over the next ten years and at the same time have a rewarding and fulfilling career.

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


Disaster Recovery and the Role of the Disaster Recovery Analyst

Disaster recovery entails processes that ensure the swift re-establishment of an enterprise’s important data, IT systems, and applications in the event of an unexpected outage caused by either a man-made or natural disaster.


The importance of disaster recovery is clear when assessing the costs to enterprises of system outages—according to a 2015 IHS study of mid- to large-size enterprises, such outages cost companies $700 billion a year across North America. The costs run so high when you consider lost revenue, loss of employee productivity, and the time taken to get systems back up and running.


It’s evident from the IHS study that recovering from system outages as quickly as possible is vital for minimizing the costs of any disaster. Below you’ll find out what a disaster recovery plan is, how disaster recovery is relevant to a business analyst, and you’ll also find out about the role of the disaster recovery analyst.

Disaster Recovery Plan

A disaster recovery plan covers the steps, policies, and tools required for an enterprise to get its technology infrastructure functioning again rapidly following a disaster. Such a plan is often developed alongside an organization’s business continuity plan.


The disaster recovery plan typically includes important recovery strategies for on-premise systems, such as using uninterruptible power supplies, backing up data to secondary locations, and even cloud-based recovery options.


AWS disaster recovery is a particularly pertinent option that emerged in recent years with the development of cloud computing, in particular those services provided by Amazon Web Services (AWS). Many enterprises now use a hybrid cloud solution that combines on-premise physical systems with cloud services such as AWS (EC2, Redshift, Aurora, etc.) to handle IT workloads more efficiently.


An enterprise can now back up its mission-critical apps and data which are handled by AWS services by using AWS disaster recovery solutions. After all, cloud computers are also at risk from man-made or natural disasters, so it makes sense to incorporate AWS disaster recovery as part of a comprehensive disaster recovery plan that covers all angles and types of system.

Who Is Responsible for Disaster Recovery?

Because disaster recovery is an important financial concern, a senior employee in the finance department should help with the development of any DR plan, such as the chief financial officer. In fact, the disaster recovery plan is of such critical importance that the central responsibility for the plan must reside on top management.


However, other employees are also responsible for helping out with drawing up an adequate plan. A committee with representatives from functional areas of the company should oversee the implementation of a DR plan.


The business analyst plays an important role in disaster recovery as the link between an enterprise’s IT and its distinct business units. More precisely, the business analyst helps to conduct a business impact analysis which analyses mission-critical business functions and quantifies the effects that a business disruption might have on those functions.

Disaster Recovery Analyst

A disaster recovery analyst is a specialist employee who helps create technical disaster recovery plans, including details on the processes for re-establishing servers, apps, databases, and operating systems in the event of a disruption (see this job description). The disaster recovery analyst tests and updates existing plans all the time to ensure they operate seamlessly and return systems to a functioning state with minimal downtime after a disaster.


The disaster recovery analyst is a relatively new role that reflects the importance of disaster recovery and the high costs that can occur when a proper plan is not in place. The traditional approach is to distribute a disaster recovery analyst’s responsibilities among several types of employee, but the argument for hiring a dedicated analyst is that he/she can better pinpoint the strategies needed for an appropriate DR plan.


Business analyst and disaster recovery analysts


A business analyst is typically seen as a professional who helps to facilitate change within an organization. As such, business analysts help to improve business processes by documenting how such processes function and helping to improve them. In this sense, a business analyst’s job could overlap with that of a disaster recovery analyst, particularly in terms of assessing the current processes and procedures used for disaster recovery.  

Closing Thoughts

Rapid recovery from man-made or natural disasters is extremely important for modern enterprises. Many companies now employ hybrid cloud solutions for managing their application workloads, which broadens the range of systems that need to be considered when protecting against a system outage. Cloud-based recovery solutions such as AWS disaster recovery can help protect data and workloads stored on cloud computers.


A relatively new role has emerged in the form of a disaster recovery analyst, who specializes in helping to create disaster recovery plans and constantly refines those plans through thorough testing.


What has a greater impact on Digital Transformation: Enterprise Architecture or Business Architecture?

Around this time 12 months ago Gartner predicted that half of EA Business Architecture initiatives in 2018 would focus on defining and enabling Digital Platform Strategies. While there hasn’t been follow up research to prove whether this prediction has come true, anecdotal evidence would suggest that the real situation is pretty close.

In the research Betsy Barton, Vice President and Distinguished Analyst at Gartner stated:

“The increasing focus of EA Practitioners and CIO’s on their business ecosystems will drive organisations further toward supporting and integrating business architecture. This is to ensure that investments support a business ecosystem strategy that involves customers, partners, organisations and technology.”

The core output of a Digital Transformation, from an IT perspective, is the development of supporting digital business platforms. However, with the growth of cloud based services success in this transformation process is less a technology challenge and more a Business Model challenge. Digital Transformation can provide an opportunity for organisations to do business in a totally different way. But the fundamentals of business in a digital and traditional world remain the same. To run a sustainable business you need to deliver a product/ service to customers that meet their needs in an effective and efficient manner and ensure that you continue to evolve that product/ service so that it continues to meet customer needs into the future. And you need to make a profit doing it. So you need to have a Business Model that achieves this.

Enterprise Architecture is very good at defining, and bringing a semblance of order to, the complex ecosystems that make up a business, particularly from a technology perspective. However, business architecture is what brings it alive. This is what Gartner calls this business-outcome-driven Enterprise Architecture, which emphasises the importance of understanding the business and how it executes on its value streams.

TOGAF practitioners will proport that Business Architecture is an inherent part of the Architecture Development Method (ADM), which is true. However, I would argue that Business Architecture should be the key driver of the ADM to deliver a successful Digital Platform Strategy, rather than focussing on some of the more traditional governance elements of Enterprise Architecture.

The really interesting aspect of the Gartner research is that Ms. Burton advises that one of the keys to success for the implementation of successful digital platform strategies will be the ability of organisations to integrate with other businesses digital platforms. While this will be a significant technical challenge the key to deriving real business value will be ensuring that the platform and integrations align with the organisations strategic intent and support its value streams. In this context Enterprise Architects will not only need to understand the business drivers and outcomes required by their business but also the needs of their partners in the digital ecosystem.

This ability to support the innovation agenda that is driving Digital Platform Strategies has also seen the rise of a new Architecture skillset, design-driven architecture. Gartner advises that “design driven architecture will allow organisations to understand their ecosystem and its actors, gaining insight into them and their behaviour which will allow organisations to develop and evolve the services that they need and consequently deliver on their business objectives”. In effect it will allow Architects to be more customer/ human centric in their designs to better meet the increasingly complex needs of customers/ stakeholders. The key skillet that will be leveraging is Design Thinking or Human Centric Design.

With millions of dollars being pumped into Digital Platform Strategies the pressure on Architects is significant. They need to be able to manage the need to innovate organisations Business and Operating Models, often within Agile Development environments, while ensuring the interoperability of these platforms with other players in the organisations ecosystem. In addition they need to delight their customers/ stakeholders and in the private sector deliver a profit! With the continued development of Cloud Based Services the challenge of delivering these objectives by developing successful Digital Platform Strategies will be less of a technology challenge and more a business challenge.

When I initially posed the question of which discipline, Business or Enterprise Architecture, has a greater impact on Digital Transformation it wasn’t to say that both weren’t important. However, if you look at the underlying value proposition of Digital Transformation it’s about doing business better and more efficiently by leveraging technology. To fully realise this promise the business models and value streams that deliver these outcomes need to be clearly defined and tested based on customer/ stakeholder needs (Design Thinking) before the development of the technology platform to support them. It is for this reason I believe that Business Architecture will have a greater impact on Digital Transformation initiatives than Enterprise Architecture!

Article written by Scott Comte, General Manager of EA Learning.


What's the Difference between Business Development, Sales Development, and Business Analysis?

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?

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, Roles, and Tools

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.

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

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?

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.

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

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?

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:

  1. The minimum password length shall be 15 characters
  2. The maximum password length shall be 30 characters
  3. The password shall contain at least one of each of the following types of characters
    1. Numeric Character
    2. Uppercase Alphabetic Character
    3. Lowercase Alphabetic Character
    4. Special Character (!,@,#, etc.)
  4. 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

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

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?

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.


Identifying requirements, the right way

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements - Functional and Non-Functional Requirements
  • Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder -  Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a.      Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

  • The features the system will support (Functional capabilities)
  • Data validation rules and how they will be managed (Business Rules)
  • Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

  • Registered users shall be able to login with valid username and password
  • On successful login, user shall be redirected to a landing page in the system
  • On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
  • New users shall be able to register with the system by clicking on the "Sign-Up" link
  • Users shall be able to recover password by clicking on "Forgot Password" link

b.     Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

  • Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
  • Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
  • Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

  • Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
  • Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

  • Textboxes for username and password shall be placed below the respective labels for Username and Password
  • Login and Cancel buttons shall be present in center of the screen
  • Sign-Up link shall be present below the Login button
  • Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements


Challenges in Implementation
 Challenges in Implementation:

 

 

I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.

 Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.

 Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.

 Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.

 The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.

 Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.

 Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.

There are number of other challenges that do a Business Analyst phase. I would love to hear. 

 


Defining Requirements

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

So, what are these requirements?

“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis

Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.

Per BABOK guide, official definition of requirement is:

1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.

2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.

3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.

Where do these requirements come from?

All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

  • Executive Sponsor — Mostly concerned about funding of the project and high-level information
  • Product Manager — Make important decisions for the project and review & approve requirements
  • Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst
  • Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified?

“The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

  • Identify stakeholders
  • Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases
  • Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements
  • Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable
  • Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are requirements important?

Per new research,

  • Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start
  • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project
  • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

  • They are used as inputs into the design stages of product development
  • They are important input for verification process for the product developed
  • They represent what functionalities are necessary for the product
Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn


Experience Age - a new era

A few weeks ago, one of my colleagues surprised me with a statement he made during our team meeting that the information technology age is coming to an end. I looked at him in complete disbelief. How can the advances that have brought so much convenience to our lives be said to be coming to an end.  I thought he must be mistaken, and just like a student who has just been given a topic for an assignment, my curious nature of always wanting to know kicked in and I set out on my little research – not to pass this time, but to prove him wrong.  I asked myself how can we live without information technology, and how can life be better without information technology, which has brought with it globalization – a concept that shrunk the world into a small village.

However, after reading a few articles on this topic, I realized that just like there were other ages before – for instance, during the 17th century human beings lived off the land, and were mainly agrarian. During the 18th century – the Industrial revolution happened – ushering in a new era in the history of mankind – the Industrial age, and continued to evolve through to the 19th century. That too subsided in the 20th century and gave way to the new kid on the block – technology, which revolutionized communication by introducing telephone, radio and television. And we have come a long way since then.

Needless to say, the advances that have been made in the technology space have been in leaps and bounds since the invention of the telephone line, and created what has come to be known as the ‘information technology’ or ‘information economy’ age. It is the world as we currently know it, and as we currently expect to operate.   However, the earth has never stopped moving….it continuously orbits the sun 365 days a year.  This means that, as much as we have felt comfortable with what we have come to know - the ‘information economy’ age – this period was also never here to stay either. At some stage, just like the earth is consistently in motion – this age would have to come to pass, and make way for a new order of things.

At the centre of the information technology age is the focus of acquiring, storing and processing data to meaningful information and insights to better organisations’ economic progress.  And as we in the first quarter of the 21st century, the non-stopping advances in technology are preparing us for a new era – the experience age. It is reported that by 2025, which is a mere 7 years away, the virtual reality experience will be almost close to the new reality – such that conscious efforts will have to be made to make people to be able distinguish between the real ‘reality’ and the ‘virtual reality’.  This age will bring with it a complete paradigm shift – from how data is collected, stored and processed to become meaning and useful information in the form of business intelligence to how consumers will experience products and services offered by organizations.

The significance of data collection and/or data mining to gain customer insights will no longer be of primary focus. The experience age will necessitate the creation of virtual reality for the consumers to experience a product and/or a service even without buying it. For example, they will feel like they are ‘physically’ at the stadium watching a soccer or rugby match, while sitting in the comfort of their homes.

 

The experience age will extend the use of technology even further. It will allow for the use of technology to enable the consumers to experience a product or a service in that moment as if it were real or as if they were already consuming it, even though they were still trying it out. Some of this might sound far-fetched and just a fantasy. However, who would have thought that the demand for voice calls on mobile devices would be replaced by the demand for data services like WhatsApp – a move that has just happened over the past 5 – 10 years? And to push the envelope even further, the demand for data services for chatting and sharing of pictures or videos will soon be replaced by demand for data services for video calls – something that Facebook has realized and now introduced video calling on WhatsApp. Consumers will demand the experience of seeing each other as they are talking to each other. Yes, this is already happened in some parts of the world, but not at the ubiquitous level at the moment.  This is the experience age shaping up right before our eyes.

The experience age will also be of great benefit to the services market. At the moment, consumers can only experience the quality of the service offered by a hotel by physically staying at the hotel. However, with the advances in the experience age, the consumer will be able to take advantage of the virtual reality and experience the stay at the hotel before actually staying at a particular hotel. At the moment, all that thought and decision making process of which hotel to choose is driven by data – either personal or impersonal, i.e. either through word of mouth from friends who have stayed over at that hotel, or through what the hotel publishes about itself on websites, brochures and other sources of information. And all of these touch points may prove, as some of you may agree with me, very deceiving and lead to a disappointing experience.

In the product market space, gamification will probably become one of the dominant form of introducing the experience age to the consumers. In this way, technology will be used to create games for customers to experience the product they are interested in even before buying it – as part of playing the game – as opposed to reading about what the product can do or see the TV ads about what a product does. 

We cannot speak about the experience age and leave out the new buzz word, the IoT – the internet of things. This concept simply means that every device with a power switch can be hooked on to the internet – the connectivity to the internet will not only be exclusive to devices such as laptops, computers, mobile telephones.  These devices include cars, televisions, fridges etc. The ability of these devices to connect to the internet will also change how we ‘experience’ the world we live in.

Cars will be able to communicate with each other, with the traffic lights, with mobile devices of the people you are having a meeting with to advise them that you are running late, to identify roads congested with traffic due to accidents or traffic lights that are out, and to decide alternative routes. Fridges will be able to contact your local supplier to order milk or whatever it is that you will be running short of. We currently see the advances made by smart TV’s which are already able to connect to the internet. Thus the IoT will be another form through which the ‘experience age’ is rendered to us by technology.

Therefore, the paradigm shift I referred to earlier on means that organizations will have to change their strategies, as the focus will no longer be on relying on big data to run analytics, but rather on using technology to provide real time experience to acquire and retain customers.  The experience age calls for a different mindset, bearing in mind that consumers are also changing. We are talking millennials now, and no longer the X’ers and the Y’ers – and they have a different view of the world – which is proving to be a challenge to both their employers and companies offering services or products to them. And I believe that this is food for thought for us in the information technology space.  In order to adapt, companies have to gear themselves and their mindsets towards IoT, robotics and experience age to remain relevant and up to date with the new era.
10 TIPS FOR A BA TO WORK EFFECTIVELY WITH A PROJECT MANAGER

EXECUTIVE SUMMARY

The Business Analyst and Project Manager are team players on a project. As is common the Business Analyst and Project Manager sometimes have conflicting approaches during a project.

Having frequently taken up dual roles of a project manager and Business analyst during the course of my career, I have gained some insight on the dos and don’ts for a business analyst to work effectively with a Project Manager

The following are the 10 recommended Tips:

TIP 1 – Collaborative Stakeholder Analysis

Key to your success as a Business Analyst on any project is identifying your key stakeholders and having a good understanding of their interests and levels of influence. From my experience this is a task best done in collaboration with your Project Manager to ensure you speak the same language when it comes to managing your stakeholders. Imagine a situation where you haven’t captured the requirements a highly influential stakeholder already identified by your Project Manager. This could in turn result in unwanted reworks on the project, increased costs and project delays.

TIP 2 – Synchronization of your Business Analysis Plan with the Project Schedule

It is good to ensure that the activity dates of your Business Analysis Plan are incorporated or synchronized with the Project Manager’s Project Schedule. Nothing is worse than discovering that the period of time the project manager has allocated for your Business Analysis Activities is insufficient.

TIP 3 – Usually not all requirements can be captured up front.

Many Business Analysts discover that as much as the intention may be to capture all requirements up front before the execution phase, there are actually few cases where this is possible. During execution it is common that stakeholders bring up forgotten requirements.  The good news is that usually the Project Manager will define the Acceptance criteria with the client. The acceptance criteria is an agreement of what the product or service should constitute for it to be accepted by the client. The Acceptance criteria are usually part of the signed off project charter.  Other Project Managers may use the agile approach where prioritized requirements are implemented in phases. In summary A BA must accept the fact that in most cases not all requirements will be captured up front.

TIP 4 – Non Functional Requirements vs. Project Scope

As Business Analysts we also capture non-functional requirements i.e. the expected efficiency level of a system. It is good to liaise with your Project Manager on what is out of scope for the Project. It is common that non-functional requirements requested by stakeholders are sometimes not feasible due to budget and time constraints. In summary you need to be on the same page with your project manager on what is out of scope. This is to avoid complicating the management of your stakeholder expectations

 

TIP 5 – Help to minimize Scope Creep

As business analysts we know that stakeholders may request additional requirements during the course of the project. As Business analysts a new requirement is accepted or rejected depending on whether it can be directly linked to the Business Need. However Business Analysts need to remember that project manager aims to minimize new additions to the project scope (Scope Creep) that will require the adjustment of the Project budget and Schedule.  In most cases stakeholders are not willing to incur the increased cost or time required for inclusion of new requirements.

 

TIP 6 – All changes to requirements undergo impact analysis

Whilst carrying out the Requirements Management & Communications process the business analyst must ensure that changes to requirements go through the Impact Analysis process managed by the Project Manager. This is to ensure that the Impact that a change in requirement will have on the Project Schedule, Project Cost or product quality is assessed before the requirement change is formally approved.

 

TIP 7 – Collaborative Prioritization of Requirements

Prioritization of requirements is a standard task that we carry out as Business Analysts under Requirements Analysis. However it is common to reach a road block where stakeholders wish to classify all their requirements as high priority. This is usually due to the fear that non high priority requirements will be excluded in the project scope. With this in minded it is recommend that prioritization of requirements is done with the involvement of the project manager to assist in management of your stakeholders.

 

TIP 8 – Synchronize the list of prioritized requirements with the vendor selection criteria

Selection of vendors is procurement management task that critically requires the input of the Business Analyst. Selection of vendors is usually based on each vendor being evaluated against the vendor selection criteria defined by the project manager. It is crucial that Business Analyst ensures that the vendor selection criteria is synchronized with the list prioritized requirements.

 

TIP 9 – Transition Requirements can sometimes be implemented as post GO LIVE tasks

Business analysts also capture transition requirements i.e. the required training of users.  For a Business Analyst a project is complete when all the categories of requirements i.e. transition requirements have been implemented.  However what is sometimes experienced is the Project Manager wishes to separate the implementation of transition requirements from the Project Scope and treat transition requirements as post GO Live tasks. This is usually the case when Project has a non-negotiable constraint on the GO Live Date.

TIP 10 –Factor in Project Manager’s constraints and assumptions when the defining the solution scope.

The Business Analysts defines the solution scope under the process of enterprise analysis. It is critical that the Business Analysts gains the input of the project manager on constraints and assumptions before defining the solution scope.

 

CONCLUSION

To work effectively with Project Manager a Business Analyst has to be able to understand aspects of stakeholder analysis , Project Schedule , Project Scope ,  Managing scope change , vendor selection criteria and project constraints from the eyes of a project manager.


job search - Google News
job search - Google News
©2018 Google
Google News

This RSS feed URL is deprecated
This RSS feed URL is deprecated, please update. New URLs can be found in the footers at https://news.google.com/news
Five Things Never To Say To A Job-Hunting Friend - Forbes


Forbes

Five Things Never To Say To A Job-Hunting Friend
Forbes
Dear Liz,. I'm job-hunting. I'm trying to keep my chin up. I know I will get hired, but it's hard to stay positive sometimes. My friends are well-meaning but they're not always helpful. They keep saying things like, "Don't worry, Samantha!" but of ...


Facts That Might Surprise You About An Executive Job Search - Forbes

Forbes

Facts That Might Surprise You About An Executive Job Search
Forbes
As a career coach, I have worked with hundreds of executives who were seeking top-level positions. In analyzing the struggles that most of these executive job seekers had before coming to me for help, I found that there were only a handful of reasons ...


These Common Reference Myths Are Hurting Your Job Search - U.S. News & World Report (blog)

U.S. News & World Report (blog)

These Common Reference Myths Are Hurting Your Job Search
U.S. News & World Report (blog)
Once you have compiled your list of references, it's important to ask for their permission to use them as references during your job search. Then, you should let them know each time you give their information to a hiring manager so they are prepared ...


The Results After 4 Years Of Job Searching With 4 Different Problems - Above the Law

Above the Law

The Results After 4 Years Of Job Searching With 4 Different Problems
Above the Law
It has been four years since I started writing for Above the Law. I started this column with the goals of documenting my job search and to write about solo practice, particularly the not-so-glamourous side. Over the last few years, I've been writing ...


Working Strategies: In job search, the waiting seems like the hardest part - TwinCities.com-Pioneer Press

TwinCities.com-Pioneer Press

Working Strategies: In job search, the waiting seems like the hardest part
TwinCities.com-Pioneer Press
You've heard the phrase, “hurry up and wait”? Although that term first surfaced related to the military — as in, hurry to your post, then wait hours for your instructions — it's an apt description for job search as well. For example, you might hurry ...

and more »

Why it's better to search for a job while you already have one - CNNMoney

CNNMoney

Why it's better to search for a job while you already have one
CNNMoney
With the expansion of online job search platforms, like LinkedIn, recruiters have even more access to those who are already employed, allowing them to bypass unemployed job seekers entirely if they want to. As unemployment stays at historic lows, that ...

and more »

Top 13 Legal Job Search Sites for Legal Jobs and Alternative Legal Jobs - JDJournal.com

Top 13 Legal Job Search Sites for Legal Jobs and Alternative Legal Jobs
JDJournal.com
A comprehensive legal career website which lists a variety of legal jobs, including positions for attorneys, paralegals, legal secretaries and other legal-related work. LawCrossing also offers job seekers informative articles for those interested in ...


Pitino Chats With Albany Sportswriter On Job Search - LEX18 Lexington KY News

LEX18 Lexington KY News

Pitino Chats With Albany Sportswriter On Job Search
LEX18 Lexington KY News
LOUISVILLE, Ky. (Times Union) - Coach Rick Pitino, after saying he wouldn't give an interview, reached out to a Albany sportswriter. Last week, Chris Churchill in Albany wrote a piece for the Times Union paper. Despite taking some pot shots at Pitino's ...

and more »

On job search, Rick Pitino still looking for someone to believe in him - The Courier-Journal

The Courier-Journal

On job search, Rick Pitino still looking for someone to believe in him
The Courier-Journal
Former Louisville coach Rick Pitino sends mixed signals about Siena opening.

and more »

Networking Speeds Up Your Job Search. Can Blockchain Systematize It? - CoinAnnouncer

CoinAnnouncer

Networking Speeds Up Your Job Search. Can Blockchain Systematize It?
CoinAnnouncer
Lately, there has been a rise of the number of articles that have been written on networking and its influence on the job search. While this is not a new concept, the overarching view of networking does bear some fundamental flaws. The most successful ...



Systems Analyst Jobs
Listed by State – Updated Daily

Alabama Alaska Arizona
Arkansas California Colorado
Connecticut Delaware Florida
Georgia Hawaii Idaho
Illinois Indiana Iowa
Kansas Kentucky Louisiana
Maine Maryland Massachusetts
Michigan Minnesota Mississippi
Missouri Montana Nebraska
Nevada New Hampshire New Jersey
New Mexico New York North Carolina
North Dakota Ohio Oklahoma
Oregon Pennsylvania Rhode Island
South Carolina South Dakota Tennessee
Texas Utah Vermont
Virginia Washington West Virginia
Wisconsin Wyoming

Powered by FirstRSS Plugin

Leave a Reply

Your email address will not be published. Required fields are marked *