Skip to main content
BATimes_Apr01_2024

How Generative-AI Can Help Modernize Your Legacy Software

Written by Jacelyn Sia on . Posted in Articles.

Legacy applications, those trusty workhorses that have powered your business for years, can start to resemble a classic car.  They might be reliable, but they lack the sleek design and efficiency of newer models.  Maintaining them can be expensive, and they often struggle to keep pace with evolving security threats and changing business needs.  A study found that 70% of enterprises still grapple with legacy applications, hindering their ability to innovate and adapt. But unlike a car you can trade in, replacing these applications entirely can be a costly and disruptive endeavor.

Here’s where Generative AI swoops in, offering a revolutionary approach to legacy system modernization. Imagine a tool that can analyze your aging codebase, understand its functionality, and then generate modern, efficient code that replicates its core functionality. That’s the magic of Generative AI!

 

7 Warning Signs Your Legacy Software Needs Modernization (and How Generative AI Can Help)

1. Frequent System Crashes and Performance Issues: Legacy software, built with older technologies, might struggle with increased data volumes and user traffic. This can lead to frequent crashes, slow loading times, and a frustrating user experience.

Role of Generative AI: It can analyze code bottlenecks and suggest optimizations to improve performance. It can also help identify areas for code modernization to handle larger datasets efficiently.

 

2. Security Vulnerabilities: Outdated coding practices and unpatched vulnerabilities can leave your legacy software exposed to cyberattacks. This puts your company data and customer information at risk.

Role of Generative AI: It can analyze code for known vulnerabilities and suggest potential fixes. It can also help developers stay up-to-date on security best practices by generating code that adheres to secure coding standards.

 

3. Incompatibility with Modern Systems and Devices: Legacy applications might not integrate well with newer software and hardware, creating data silos and hindering operational efficiency.

Role of Generative AI: It can analyze APIs and suggest code modifications or generation for seamless integration with modern software development. This allows your legacy application to communicate and exchange data effectively.\

 

4. High Maintenance Costs: Maintaining legacy software can be a significant drain on resources.  Bug fixes, code updates, and compatibility issues can require a dedicated team of developers with specialized knowledge of the aging codebase.

Role of Generative AI: It can automate tasks like code documentation and code refactoring. This reduces the need for manual maintenance and frees up developers to focus on more strategic initiatives.

 

5. Lack of Features and Functionality:  Legacy applications might lack the features and functionalities of modern software, hindering your ability to compete and meet evolving customer needs.

Role of Generative AI: It can analyze user interactions and suggest improvements to the UI/UX. It can also generate code snippets for modern UI frameworks, allowing developers to create a fresh and user-friendly experience.

 

6. Difficulty in Finding Developers with Legacy Expertise: As technology advances, developers with expertise in older programming languages and frameworks become scarce. This can make it challenging to find qualified personnel to maintain and update your legacy application.

Role of Generative AI: It can bridge the knowledge gap by automatically generating code that replicates the core functionality of the legacy application. This allows developers with modern skill sets to contribute to the modernization process.

 

7. Limited Scalability: Legacy applications might not be able to scale to accommodate future growth or increased demand. This can stifle your business potential and hinder your ability to expand.

Role of Generative AI: It can analyze code for scalability bottlenecks and suggest optimizations. It can also generate code for integrating with cloud platforms that offer greater flexibility and scalability.

 

Advertisement

 

Step-by-Step Process to Modernize Legacy Software with Generative AI

Step 1: Identify Target Applications:

Begin by prioritizing which legacy applications require modernization the most. Focus on systems critical to business operations or those causing significant pain points.

Step 2: Inventory and Analyze Existing Systems:

Document your current technology stack, including programming languages, frameworks, and databases used by the legacy application. Analyze the codebase to understand its functionality and identify areas for improvement.

Step 3: Code Refactoring and Optimization:

Utilize GenAI tools to analyze the codebase and suggest automated refactoring options. This can involve removing redundant code, improving code readability, and optimizing for performance.

Step 4: Modern UI/UX Design:

Use GenAI to analyze user interactions and data to identify opportunities for improving the user interface and user experience. Generate code snippets or mockups for a modern and intuitive design.

Step 5: Incremental Modernization:

Modernize the legacy application in phases to minimize disruption and risk. Start with smaller, less critical functionalities and gradually work your way towards core components.

Step 6: Continuous Integration and Delivery (CI/CD):

Implement a CI/CD pipeline to automate code testing and deployment. This ensures rapid integration of GenAI-generated code with minimal errors.

Step 7: Monitoring and Performance Analysis:

Continuously monitor the performance of the modernized application and address any potential issues promptly. Utilize AI-powered monitoring tools for proactive problem identification.

BATimes_Apr24_2024

The Pitfalls Of Efficiency: Process Improvement Is A Balancing Act

Written by Adrian Reed on . Posted in Articles.

Business analysis work often involves improving processes. This might include simplification of a process, reengineering or automation. When used well, IT can be used to enhance (or even completely rethink) a process. The ideal outcome is to design a process that is quicker, more convenient and more cost-effective than what it replaces.

 

When aiming for efficiency, it’s important to ask “for whom are we optimizing this process?”. This might sound like an odd question to ask, but often there’s a fine balancing act. A process that appears very efficient for a company might actually be very inefficient and inconvenient for its customers. Standardizing a procurement process might create internal efficiencies for the company involved, but might place additional work on the company’s suppliers.

 

An Example: “No Reply” Secure Email

I was recently a customer of a company that would send correspondence via secure email. I’d receive a notification via regular email, and I’d then need to log in to the company’s secure email portal to read what they had sent me. This was fine, except the emails they sent were all from a ‘no reply’ address.  While the secure email system they had implemented literally had a ‘reply’ button, there was a disclaimer on every email they sent which said “don’t reply, as we won’t read what you send us” (OK, it wasn’t that blunt, but you get the idea!).

This led to the crazy situation where the only way of replying to their secure emails was to either call via phone (and queue for 45 minutes), or put a reply in the mail.

 

This is an example of a situation where convenience and savings are predominantly biased towards the company, with some minor benefit for the customer. Prior to sending secure email, they would put correspondence in the regular mail. Moving this to an electronic platform presumably saves in printing, postage and stamps. It’s of marginal benefit to customers too, as they receive correspondence quicker (providing they look at their email regularly).

But the real customer benefit would have been to be able to correspond and reply with the company via secure email. Ironically, by implementing the solution the way that they did I suspect their ‘no reply’ mailbox is actually full of replies from customers who didn’t read their disclaimer!

 

Advertisement

 

There is no “right”, it’s a balance

As a customer, I found the situation frustrating, but there is no inherent or universal ‘right’ answer here. It might be that the company in question had deliberately chosen not to accept incoming secure email for compliance reasons, or perhaps they feared they’d be flooded with lots of customer inquiries as they are now ‘too easy’ to contact (although I’d argue that if this is the case then there’s probably a bigger root cause they ought to be contending with!).

 

The point here is that it should be a conscious balancing act. It is all too easy to create a situation that is more efficient for one group of stakeholders, but actually worse for another. An employer who decides to streamline their process for employees who need to claim travel expenses might decide that they can save time if they ask their employees to input more data at the time they submit their claim. If they get the employee to select where the expense was incurred, the amount of sales tax that was included in the expense, the category of cost and so forth, then this saves time later. Yet an employee who isn’t a tax expert might find this frustrating (“Is train travel exempt, or zero-rated for sales tax?”). Of course, in reality this will likely affect the quality of data too, as people try their best (but don’t know which of the different tax code options to choose).

This is a specific example, but it highlights a wider point: it’s important to consider process improvements from the perspectives of the stakeholders impacted. This involves considering what efficiency as well as effectiveness looks like for each key group.

As with so much in business analysis, stakeholder identification, engagement and empathy is key!

 

BATimes_Apr18_2024

Beyond Frameworks: Agile Insights from a BA’s Odyssey

Written by Afaq Qazi on . Posted in Articles.

Reflecting on my journey from a Junior Business Analyst to a seasoned Business Analyst and eventually evolving into a role where Business Analysis and Product Management intersect, I’ve had the privilege to contribute to organizations as diverse as Boeing, Rolls-Royce, and EPAM, alongside navigating the unique challenges of smaller entities.

This path, spanning over 13 years and multiple domains, has equipped me with a deep understanding of Business Analysis from the grassroots, teaching me the crucial balance between adhering to frameworks and embracing the agility necessary for today’s dynamic business environment. This narrative is an exploration of that journey, emphasizing the transition from rigid methodologies to agile adaptability, and the critical importance of customer focus and stakeholder management.

 

In the early stages of my career, the allure of frameworks was undeniable. They presented a structured way of understanding Business Analysis and Product Management, offering a semblance of control and predictability in the chaotic realm of project management.

However, as I progressed, the limitations of these frameworks became increasingly apparent. The real-world application of Business Analysis goes beyond the confines of any framework. It demands an acute awareness of the shifting business landscape and the ability to think on one’s feet—a blend of deep analytical thinking and pragmatic street smarts.

 

This evolution in perspective was mirrored in my approach to project management. Initially, my focus was on mastering the technical aspects: understanding the ‘what’ and ‘why’ to navigate towards solutions and create value for users. Yet, I quickly learned that the essence of effective Business Analysis lies in the ability to communicate, adapt, and understand the broader business context—skills that are foundational yet flourish only with experience and deliberate practice.

 

Communication emerged as the cornerstone of my professional development. The capacity to engage with a diverse set of stakeholders—customers, engineers, designers, and executives—and synthesize their insights is paramount. It’s a skill that goes beyond mere articulation; it’s about understanding the audience, choosing the right words, and effectively conveying complex ideas in a manner that resonates.

This skill set has been instrumental in navigating the complexities of projects, ensuring alignment across teams, and driving towards common goals with clarity and purpose.

 

As I embraced the agile methodology, the importance of flexibility became glaringly evident. Agile is not just a buzzword; it’s a mindset that values adaptability, customer-centricity, and continuous improvement.

It challenged me to think differently about project management, to be more iterative in my approach, and to prioritize direct feedback loops with stakeholders and customers. This agility has been crucial in climbing the project ladder, allowing for rapid pivots and adjustments in response to new insights or changing market dynamics.

 

Customer focus and stakeholder management have been the bedrock of my growth as a Business Analyst. Recognizing the criticality of these aspects, I’ve dedicated myself to becoming adept at navigating the complex web of stakeholder relationships and ensuring that the voice of the customer is always at the forefront of decision-making. This has involved honing my ability to manage expectations, articulate value propositions clearly, and foster an environment of trust and collaboration.

 

Advertisement

 

In retrospect, the journey from adhering strictly to frameworks to adopting a more flexible, agile approach has been transformative. It has taught me that while frameworks provide valuable guidance, the essence of Business Analysis and Product Management lies in the ability to adapt, communicate effectively, and maintain a relentless focus on the customer and business objectives.

As I continue to navigate this ever-evolving landscape, these insights will remain central to my approach, guiding my decisions and actions in the pursuit of creating meaningful, impactful solutions.

BATimes_Apr17_2024

4 Tips for Managing Ambiguity as a Business Analyst

Written by Giorgos Sioutzos on . Posted in Articles.

As a business analyst, it is common to face ambiguity in many different forms and aspects. It may be the ambiguity of the business analysis approach you have chosen, the requirements, or the design decisions that you have to contribute to.

Ambiguity and constant changes are something that is expected. It’s up to you to respond constructively. The following tips may help:

 

#1- Approve Ambiguity

Although you may want to have full control over the circumstances, it will not happen. It may take time and changes in order to establish a business analysis approach to customers’ needs or understand the full aspects of the system to be developed. It is fine not to have the full picture from the beginning of the analysis journey, but it is your job to progressively clear out the context and the scope. Approve the ambiguity of the intrinsic part of the analysis.

 

#2- Mindset Shift

Ambiguity can cause plenty of negative thoughts and worries. Instead of entering into a negative, endless dialogue, try to view ambiguity as an opportunity for new approaches, for innovation, and for gaining experience. Ambiguity can cause team members frustration and challenges, as the situations triggering it are mostly out of our control. It is important to reframe biassed thinking patterns concerning ambiguity into positive ones.

 

Advertisement

 

#3- Utilizing Effective Risk Response Strategies

As a business analyst, you should cooperate with the project manager to recognize factors and assumptions that can affect the business analysis objectives. You have to understand the sources of the risk and craft alternatives you can use if those risks actually occur. Whether you are a lead business analyst or other team member, your ability to identify and respond to risks effectively will affect the team’s ability to successfully complete project tasks.

#4 – Have a Compass

Having a specific compass for ambiguous situations is essential to guiding your decisions and actions. Orienting yourself and leading your team through a period of ambiguity can be supported by a stable and valuable foundation of personal and organizational vision, mission goals, and objectives. Knowing at any time why you are doing something and what you want to achieve and being true to yourself and your team can guide you as the North Stare in unpredictable and chaotic situations.

 

By viewing ambiguity as an opportunity, you can reduce the stress imposed by an ambiguous situation, experiment with new processes and ideas, and develop your team members. Identifying a goal or value that can be used as a “compass” can contribute to avoiding actions and behaviours you will regret later.

BATimes_Apr11_2024

Don’t Let Your Software Requirements Die

Written by Chris Rickard on . Posted in Articles.

In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential. 

 

Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software’s lifecycle, promoting adaptability and precision in development processes. 

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information – because often zero documentation is worse than out of date documentation!

 

How requirements slowly die.

Picture this: a new software project kicks off with energy and optimism. The business analyst dives deep, engaging with stakeholders to gather an amazing set of requirements. They craft an impressive functional specification that serves as the project’s North Star, and as the project kicks off, hundreds of tasks get populated into a project management tool like Jira, mapping out the journey ahead.

The software delivery team starts strong. 

 

As expected, questions and clarifications emerge, evolving the requirements a little. Some tasks need tweaks; others have missing components, and there are even some sew requirements that surface. This is fine (we are agile after all!) – and these changes and additions are all added into the project management tool, as that’s now the source of truth keeping the project on track. 

As the tasks are ticked off, a sense of accomplishment fills the air. Finally, the project crosses the finish line, the board clears, and it’s a wrap. Success!

Or is it? Software, particularly the large, mission-critical kind, is never truly ‘done.’ 


The project may have ended, but the software lives on, continuous adaptation and enhancement are normal these days. But scoping new tasks becomes a little harder, as the detailed system knowledge from that original functional specification, has now changed. The source of truth is now fragmented across completed Jira tasks and buried in comment threads. 

In this scenario, the requirements didn’t just become obsolete; they died a slow death, leaving the team navigating a labyrinth of past decisions and discussions to grasp the full scope of their own software. 

 

Advertisement

 

How to keep my requirements alive?

Keeping software requirements alive is pivotal for the long-term health and adaptability of your system. Rather than relegating these crucial insights to a static document, consider embedding them within a collaborative platform accessible to the entire organization. This living, breathing approach ensures that requirements can evolve alongside your software, reflecting real-time changes and decisions. Here’s how you can make it happen:

 

1. Centralize requirements and allow collaboration: Choose a platform where stakeholders across the business can access, review, and iterate on the requirements. This system should be the go-to source for everything related to what your software does and why, and platforms such as Userdoc are specifically tailored to this task.

 

2. Project management integration: While the main body of requirements should live outside, ensure there’s a seamless flow of information into your project management tools like Jira. This helps in translating the high-level requirements into actionable tasks and ensures day-to-day activities align with the broader goals.

 

3. Continuous updates and iterations: Encourage a culture where updating the requirements is part of the process, not an afterthought. This keeps the requirements current and relevant throughout the software lifecycle.

 

4. Embrace AI – AI can be an amazing tool for helping determine what changes could affect other parts of your system, and understanding that when writing requirements for New Feature X, you will also need to update Existing Feature Y’s requirements.

 

5. Requirements versioning: Just like with code, software requirements need versions and branches. Ensure you clearly denote what features are live, what features are in development, and what features are still being scoped.

 

6. Living reference for all teams: From development to QA, from business analysts to project managers, ensure that everyone references and contributes to the same set of requirements. This alignment prevents information silos and fosters a unified understanding of the system.

 

7. Long-term business asset: Beyond project completion, maintain these requirements as a living record of what’s in place. This becomes invaluable for training, onboarding, and new developers understanding the system’s capabilities and limitations. It also ensures the source code isn’t the only source of truth for the system’s functionality.

 

Transforming your software requirements into living documentation is a strategic move that pays dividends throughout the lifecycle of your software. 

And the thing is, it’s not actually doing any extra work – it’s just simply unifying the place where that work is done, and fostering a culture of continuous collaboration and documentation.

Embrace the concept of living software requirements and watch your software, and team, move faster with more confidence.