Tag: Methodologies

Virtual Collaboration

Written by Poorti Mehta on March 14, 2018. Posted in Articles.

What are the major modules of any application development project?

Requirement Gathering (this one requires some rigorous re-iterations)
Approval from all stakeholders and drafting a BRD (Business requirement document)
Defining a Scope of Work for the project
Preparing other documents such as process flow diagrams, technical documentation, module trackers, reports etc.
Development activities
Performing tests on the UAT environment followed by bug reporting and bug fixing

And once all these activities are taken care of, there’s a production movement.

But it doesn’t stop here. There are change requests from stakeholders and thus begins the change management process which eventually ignites the version control process.

While we are on this journey, we face certain challenges. Some of those pictures look like this:

You get notified that there’s an external technical audit next week and you have to get all the relevant documentation sorted. Gosh where were the release notes saved? Are the documents in order? A change was requested on the home page 3 months back. Where are the details?
My system has become a warehouse of documents. I spend so much time organizing the repository that organizational skill should be included in my KRA.
Requirements for this project are changing at lightning fast speed. This wasn’t the case with my last project.
I don’t exactly remember the details of this feature. Wait let me check my e-mail from the stakeholder who had explained it to us. *About 150 emails later* Well, I will just ask him to forward that mail to me.

As a BA I have had my own share of experiences at every step of an SDLC. Over the years what I have realized is that organizations need to invest in appropriate tools and software for a smooth project execution and thus I can’t emphasise on the use of good project management tools just enough.

When I started out as a BA, I learnt the basic documentation that’s common for any software project. Just like many of us on this forum, I too didn’t completely understand the great necessity of documenting each and every step then. It wasn’t until after my first software project went live, that I could see the picture more clearly.

Change requests started pouring in quite frequently and we had some new developers absorbed to the project. And thus came more documentation, version controls, diagrams, trackers and so on. From just one folder, this project grew into 6 -7 folders on my system. Innumerable mails were exchanged to discuss even the smallest and yet an important aspect of the website (read – colour of a button on a webpage). When the new developers were to be briefed about the project, I spent a lot of time in figuring out the relevant documents to be shared with them. Documents that would give them clarity on the process and the progress of the assignment. Sometimes, the stakeholders would lose track of the progress or would misplace a document or go through an incorrect file. In this chaos I realized that a lot of effort was being wasted to maintain the Collaboration.

Collaboration – A significant aspect of any project and a key skill for a BA. Project management and collaboration tools and software are a great way to minimise this chaos and they do wonders for a project’s lifecycle. I learnt this the hard way.

For my next project, we made use of a leading collaboration software. Everything right from requirement gathering to scope of work to change requests, were captured in this application. There were a lot of advantages of using this software:

It could be accessed by all the stakeholders. Hence, whatever changes were made to the requirement or any other module, everything could be viewed by all.
All the relevant documentation was uploaded here. The changes were made online.
The project plan was chalked out smoothly with supported Gant charts.
Feedback notifications were received on real time basis and this helped in faster sign off of modules and requirements.
All the project essentials were stored at one place. Unlike the earlier project where everyone had to maintain a separate repository, the repository of this project was stored online. All the literature at one place – securely stored.
The developers were making notes hassle free.
The milestones of the project could be efficiently tracked.
Lesser emails were exchanged. I didn’t have to send that scope for sign off again or send the updated tracker over and over again.
I didn’t have to worry about the back up of documentation. Version controls were in place.
With a user friendly interface, it was fun working on the documentation and creating user stories. As I got to work on more documentation, I received some very constructive feedback form my immediate seniors and this helped me to improve my data capturing skills. It was here that I understood the importance capturing even the tiniest of detail related to a web page. As all my seniors were on the same project space (of the application) they could view the work I was doing and thus I had feedback from everyone.
Presentations to all the stakeholders became easy and necessary documents and reports could be extracted during audits.

With this change in the process, the first cut of the project was delivered in just 4 months (as compared to 6 months in the earlier project). This is how virtual collaboration helped us.

With such user friendly applications and so many of them in the market, organizations should not hesitate to invest in these applications for their projects. For small size companies, there are open sources available in the market too. Also with most of these applications offering a free trial period, one can explore the best fit for a project. Tools that ensure effective collaboration can make project execution easy. Making the best use of the cloud technology, these applications are a complete back up of a project’s records and documentation.

What tools / applications have you worked upon? Have you faced any similar challenges? Please share your organizational experiences and the challenges you faced that prompted your organization to implement a better architecture.

Business Analysis for Regulatory Reporting

Written by Anindita Sarkar on March 7, 2018. Posted in Articles. 1 Comment on Business Analysis for Regulatory Reporting

Regulatory Reporting is submission of raw or summary data to the Regulators who determine the Financial Institution’s overall health by assessing the compliance needs according to regulatory provisions especially post the financial crisis.

Business Analysts understanding these requirements and providing solution that automates and streamlines the process to generate these reports in timely fashion is the need of the hour.

KEY COMPONENTS OF REGULATORY REPORTING

As a business analyst understanding of these key components of a regulatory reporting is key to delivering the right solution:

In the Regulatory Reporting world which is ever changing, business analysts need to be up to date with regulations and be well versed with data space in a financial institution.

KEY ROLE OF BUSINESS ANALYST IN REGULATORY REPORTING

As a business analyst one can lead and direct in the regulatory space by:

Business analysts can translate these regulatory reports into business requirements and further advice data quality rules and control framework relevant to the financial institution. Challenging role as BA accelerate and excel in this ever changing world of regulations and become key drivers of meeting regulatory requirements.

Using prototypes to write requirements

Written by Poorti Mehta on March 1, 2018. Posted in Articles. 1 Comment on Using prototypes to write requirements

When I started out as a Business Analyst, I worked on many small projects that dealt with internal application development.

Requirement elicitation was easy as the requirements were precise and the user navigation steps were simple. I didn’t have to think much from the design and spacing perspectives as all the stakeholders, and end users were from within the organization, and as long as the purpose of the application was being served, the design of the application would take a backseat.

But as I progressed and took up bigger projects – projects that were creating revenue for the organization and that were being used globally – I realized that I had to be very careful in writing the functional requirements. I had to be aware of each and every functionality on that screen to make the requirements more effective. The user management had to be explained in detailed, and I had to keep in mind the design of the application and be more though with the navigation flow.

Initially, I used to take the visualization approach in writing the functional requirements – Imagine the flow in my head and keep writing. However, when I reviewed these requirements, I observed that I did miss out on some aspect or the other. Eventually, I had to add more details to complete the requirements.

I then began to use prototypes to write the functional requirements. Remember how back in school we were told to use paper for rough work to do our mathematics calculations. In the same way, using prototypes to solidify the navigation flow can be a good approach.

As per many, a prototype or a mock-up is defined as the blueprint of screens or a visual guide that represents the skeletal framework of a website. A better version of a mock-up is a wireframe. Wireframes take into account the complete design aspect of the software. Mock-ups are rough drafts created in the beginning to put the elements of a website in place.

Take this for instance – you are required to spearhead a project in which an application has to be developed with which end users can buy fashion accessories. Some of the initial questions you may ask the stakeholders would be about:

Customer base
User journey
How will the payments be processed? The payment gateway integrations
If user can make a purchase as a guest user
Where will the user apply the promo codes?
Which filters can be used by a user?
Are we maintaining any order history?

The answers to these questions will help in drafting the high-level requirements. But what about the following questions?

What all can a user do in his / her account? – Change profile
How will the navigation between pages be? This may seem simple, but the stakeholders may have a different opinion. For example, you may think that when a user is on the review order page, and when the user clicks on continue shopping, s/he should land on the product listing page. But the stakeholders have a different requirement – They want the user to land on the home page of the website. BAM there’s a gap now!

Case – Requirements without a prototype

Let’s say you are to capture requirements for the order history page in the user’s account. You imagine the page in your head. You first write about the basics – The page will have the following details:

Order No
Product details
Total amount
Promo Code discount
Amount paid
Status

Case – Requirements with a prototype

Now, what about the details at the granular level. You make a mock-up with the information above and analyze the order history page further.

Can the user click on the product details and view the different products in list form? If yes, then can the user select each product to view its detailed page?
Can the user view the amount breakup and the mode of payment?
Will the status be a pictorial representation or just a text?
Where will the images of the products be placed?
Given the layout above, how will the space to the right be utilized? If the stakeholders request to add some banners how that will be done?
Does the return and exchange of a product happen on this page?

This is just a small module. When it comes to the entire application, the complexity may increase, and the requirements may have to write in much detail.

Mock-ups are the binding agents of the requirements. They help in understanding the user journey which can eventually help in effectively drafting the use cases. These are easy to make and are effective in identifying gaps. While various tools are available in the market, mock ups can be done in the basic pen paper mode too. One doesn’t need to be adept with the design aspect. However, a BA should consider each aspect of a screen and make sure if there’s a requirement associated with it. The main purpose of a mock-up is to have a complete picture of the user journey. Moreover, the feasibility of the features can also be assessed.

Having a mock-up for reference can be helpful in the following ways:

Functional requirements can be written in a modular way. As mock-ups deal with all the screens of the software, one can map the navigation amongst these pages and write details about the user journey.
It helps in filling up the requirement analysis gap. For example, during requirement elicitation, the stakeholders may skip a feature. However, if a rough structure is in place in these sessions, the chances of missing a detail are minimal.
One doesn’t miss out on a user story. For example, the order history is in place but as a user, can I sort/filter the records? If I click on an order, can I see the detailed page of a product purchased?
Requirements when coupled with mock-ups give a clearer idea to the developer who can consequently code with confidence.

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

Written by Scott Comte on February 21, 2018. Posted in Articles.

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 organizations further toward supporting and integrating business architecture. This is to ensure that investments support a business ecosystem strategy that involves customers, partners, organizations, 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 organizations 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 emphasizes 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 focus 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 organizations 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 organizations 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 organizations to understand their ecosystem and its actors, gaining insight into them and their behavior which will allow organizations 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 organizations Business and Operating Models, often within Agile Development environments, while ensuring the interoperability of these platforms with other players in the organization’s 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 realize this promise the business models and value streams that deliver these outcomes need to be 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!

Does Agile need Architecture to be successful?

Written by Scott Comte on January 31, 2018. Posted in Articles. 1 Comment on 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!