Data Classification and Information Protection

 Depending on type and nature of data it can be classified into various levels. Each level needs respective protection mechanism hence its important to understand and classify data into appropriate classes. Generally its classified from class 1 to class 5: 

Class 1 (Public): Information considered public is classified as class 1 data. Example, non sensitive information in an organization available for external use. 

Class 2 (Internal): Information generally available to employees and approved non employees. Example, Unpublished intellectual property, building layouts etc...

Class 3 (Confidential): Sensitive information within an organization, intended to be used by only specified groups of employees. Example,  financial information, information protected by privacy laws etc.

Class 4 (Restricted): Information that is extremely sensitive and is intended to be used by individuals only within an organization. For example, Personally identifiable information, credit card numbers, personal health care information. 

Class 5: Information that would cause severe harm to individuals or organizations if disclosed. Class 5 data includes individually identifiable information which if disclosed would create risk of criminal liability, loss of insurance or employability, financial, social or psychological harm.

Matrix Organizations: How do they Work?

What is Matrix Organization? 

A multidisciplinary team with members from various functional units of hierarchical organizations are also referred as "Matrix Organization". Such teams are usually built around a purpose or specific task referred as project. These became popular as problems and projects become more complex and the inadequacy of the hierarchical organizational structure became clear. 

The matrix is built up as a team of personnel drawn from both the project and the functional or disciplinary organizations. 

The primary reason for such organizational structures is that, it can handle significant complexity of a multidisciplinary effort. Because it requires multiple functions with respective expertise to come together for a project. Some examples are as follows:

What are the Pros and Cons?

Matrix organization has many advantages which help outweigh its main disadvantage of complexity. 

Pros of Matrix Organization

Key characteristics which can be turned into advantages are:

Clear Project Objectives Clear definitions are setup for project which helps functional organizations to clearly define and align objectives if they are not already. 

Integration of subsystems through coordination among functional lines. 

Efficient Resource Utilization makes matrix organization generally less expensive than an equivalent pure project organization.

Effective flow of information and learnings across projects is easier in a matrix organization as information of use to other projects is not locked up within a single project.

Retention of functions and teams Even when projects come and go teams are retained. So loss of knowledge is prevented at the closure of projects and specialists like to work with specialists of the same group enhancing Innovation and productivity as compared to working alone in projects. 

More celebration through success of projects: Successful project deliveries keep the morals high. Connecting to specialists of same functions also helps to get clarity and confidence in career progression up on respective functional ladder.

Development and training platform for project managers with promise and potential. 

Easy closure of projects without trauma and pain. Large layoffs are avoided through cross project Utilization.

Challenges in Matrix Organizations:

While matrix organization has a lot of advantages, they have lot of challenges which need to be addressed to ensure expected deliveries from projects. Some of the common challenges of a matrix organization are Multiple bosses, complexity, difficulty in monitoring, slow reaction, conflicting priorities and guidance. 

While found in conventional functional organizations also but, matrix organizations are more vulnerable to power struggles, anarchy, groupitis (solution: Group decision making should be done as often as necessary, and as little as possible), collapse during economic crunch(matrix organizations seem to blossom during periods of rapid growth and prosperity), excessive overhead (though as the matrix matures, these overhead costs decrease and productivity gains appear), decision strangulation, sinking(difficulty in keeping the matrix viable), layering, and navel gazing(tendency to become absorbed in the organization’s internal relations at the expense of the world outside the organization, particularly to clients).

In matrix organization, power struggles are a logical derivative of the ambiguity and shared power that has been built purposefully into the design. 

Building a Productive Matrix 

So a Matrix organization can be crafted to be productive for the success of the projects they exist.

Top Management support 

Top management must give real and immediate support to the matrix, including a clear project charter. This charter should state the purpose of the project and spell out the responsibilities and authority of the project manager. In addition it should indicate to the fullest extent possible his relationships with the functional managers involved in the project.

Adoption by Functional Managers, Project Managers and Project Personnel 

Functional managers need to change the way they determine their priorities. It may be a considerable shock to functional management to find that their priorities must change, and that the project comes first.  Project management must realize that they get their job accomplished primarily through the process of negotiation, and that they should become negotiation experts. If all major decisions are made with the concurrence of the involved functional managers, the project manager finds himself in a very strong position in insisting that the decision be carried out and that the desired goals be accomplished. In addition, the project personnel must be able to adapt to the two-boss situation which can be a traumatic experience when first encountered.

Balance between Functional and Project Managers 

At the heart of the operation of the matrix is the balance of power through clear definition of roles and responsibilities of functional managers and project managers. 

Project Manager’s Responsibilities

1. What is to be done?
2. When will the task be done?
3. Why will the task be done?
4. How much money is available to do the task?
5. How well has the total project been done?

Functional Manager's Responsibilities

1. How will the task be done?
2. Where will the task be done?
3. Who will do the task?
4. How well has the functional input been integrated into the project?

Another way of stating the roles is: the project manager is responsible for the overall integration of the total project system and the functional manager is responsible for technical direction in his discipline.

A useful tool is RACI MATRIX filled in during a meeting of all concerned managers resulting in agreement on the job responsibilities. 

Preparing RACI matrix with all stakeholders results in potential conflicts being resolved early, before specific problems arise. An example of RACI is as follows:

Project Manager has to be the Axis

Since the project, program or product is usually a very important part of a company’s activities, the project manager is a very important person. He is the one who puts the company in a position where it can make more profit, or lose money.

Some conscientious, knowledgeable project managers would not get personally involved in “how will the task be done?” However project schedule and “when will the task be done?” responsibilities do not allow the luxury of sitting back and waiting for functional management to make every technical decision. 

• PM must ensure that technical decisions are made on schedule. 
• PM Must review the key technical decisions and challenge them if necessary. 
• As project integrator, has the overriding responsibility for evaluating every key project decision 
• PM should determine how it interfaces with the other project tasks, and with project schedule and budget. 

The project manager therefore must get involved and influence every project action and as a last resort he always has appeal rights or veto power — for the good of the project. The project manager even gets involved in “who will do the task?” After all, the highest achievers and most innovative personnel in the discipline organizations will be highly sought after, and the project managers will seek to obtain only the very best people for their projects.

Cooperation and negotiation are the keys to successful decision making across the project/functional interface. Arbitrary and one-sided decisions by either the project or functional manager can only lead to or intensify the potential for conflict.

Very strong top-management support for the project manager is necessary to get the matrix to work, and even very strong support will not guarantee project success. However, the matrix will not work without it. The project manager must get the job done by every means at his disposal even though he may not be perceived as the real boss. He can always appeal to higher authority, however such actions must be kept to a minimum or top management may view the project manager as ineffective.

Relationship is a Two Way Street: KEY to Success 

Consultation, cooperation, and constant support are particularly necessary on the part of the project and functional managers. Relationships between Functional and Project managers are very important relationships and are keys to the success of any matrix organization, and must be carefully nurtured and actively promoted by top management and by both project and functional management.

While the matrix organization actually is a method of deliberately utilizing conflict to get a better job done. The project team must be more concerned with solving the problem rather than with who solves it. Teamwork and problem solving must be emphasized rather than role definition.

Supporting the Project Manager: Provide Clout

It is not just a question of balance of power, but does the project manager have sufficient clout to be effective? For the most part, the project manager’s clout is a direct function of the level at which he reports in the hierarchical organization. 

The project manager must be on at least an equal level with the highest level of functional management that he must deal with.  

Tweaking the Balance of Power 

The balance of power can be tilted in either direction by changing any one or any combination of the following three factors:

• Administrative relationship: The levels at which the project and involved functional managers report, and the backing which they receive from top management.
• Physical relationship: The physical distances between the various people involved in the project
• Time spent on the project: The amount of time spent on the project by the respective managers

These three factors can be used to describe whether the matrix is strong or weak. The strong matrix is one in which the balance of power is definitely on the side of project management and vice versa. 

Summary 

Matrix organization has greatly added to the versatility and effectiveness of project management. The matrix has permitted project management to be effective not only for very large projects but small projects as well, and has been extremely valuable for solving multidisciplinary problems.

The matrix organizational form is only desirable if there is a real need for its added complexity. Not only is it not for everyone, but it cannot be guaranteed to work. It will only work if the entire organization, from top management to the project personnel, are thoroughly “sold” on the matrix concept. There are many reasons why the matrix will not work, but failure to lay the groundwork and fully prepare the organization is the principle reason for failure. The matrix will function and result in very improved project productivity if top management gives its unwavering support and if functional management and the project personnel accept the matrix as a “way of life” which can only be of great advantage to the company in improving output and profit.

Source: PMI.org

North Star Engineering Principles For Successful Software Development Organisations

In the world of fintechs, digital payments and technology transformation its critical to have a defined north star of engineering principles. This defined north star of engineering principles keeps organisations and their workforce to stay on course of its purpose, its customer, its products and the promise made to its stakeholders with minimal or no digressions. So let's take a look at evergreen principles which should always be kept as north guiding development organizations. 

Evergreen Principles

User experience at the heart of engineering

Solving a real user problem should be an essential purpose of any software. Once ready, user experiences of using the software solution is critical to success. Customer delight is ultimate goal that needs to be targeted and tracked religiously. Metrics need to be defined and adopted to measure user experiences. Some of them can be behavioural (what users does) and some of them can be attitudinal (what users say). Constant monitoring of behavioural (error rate, time for task, response time) and attitudinal (Customer Satisfaction Score(CSAT), Net Promoter Score (NPS), System Usability Scale (SUS)) user experiences should be a mandatory for all organisations.

Plan for these, right from the start.

Security needs to be at the top of the table

In financial world security takes a defacto number 1 position. Though this is true for most other domains, apart from financial domain. Since protection of the users (business and consumer) and their data in an increasingly sophisticated cyber world is critical, to build the trust required to onboard and retain customers. Lack of security can quickly hurt businesses built over time through loss of revenue, intellectual property, and reputation. It should always be a top priority, no matter what software you build, operate or use.

Standard software security practices, such as no trust between application interfaces, protection of data at rest and on move, secure coding practices for developers, regularly reviewed authentication and authorisation policies should be a part of DNA of every software development company.

Build and Design Supporting Run Agility and Scalability from Start

Right from the start of SDLC the speed of delivery and scalability needs to be thought through. Every enabling factor needs to be brought in and every factor that slows down or blocks scalability needs to be weeded out. Ensuring simplicity and repeatability through design and implementations are key. Availability, redundancy needs to be factored in at start to ensure 'it always works' solution/user experience is delivered. 

At the same time overdoing can drag down, take build maintenance and operations costs higher, killing a software business unit or making it inefficient to compete in market. 

Questions like following need to be answered: 

Do we have single codebase to deploy ephemeral and disposable solution instances at will?  

Do we have single point of failures? 

Do we have automated zero downtime deployment capabilities? 

Do we setup and teardown automated tests and environments, similar to production? 

Are we active active behind load balancers? 

Do we need and have infrastructure as code capability?

Is design supportive of scaling up and down quickly?

 

Automated Testing is Critical 

Consider application/service code to be incomplete if it is not covered with automated test code for unit, functional and performance testing. Tests should be included in deployment process and service management process. Tests should include the validation of deployment and service management process. 

Always Build 12 Factor

Following is an introduction provided to 12 factor application methodology:

"Software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

• Use declarative formats for setup of automation, to minimize time and cost for new developers joining the project;
• Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
• Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
• Minimize divergence between development and production, enabling continuous deployment for maximum agility;
• And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc)." 

Let's take a closer look at twelve factors. The twelve factors to build software as a service successfully are:

1. Codebase: Have one version controlled codebase, capable of deploying ephemeral instances.
2. Dependencies: Explicitly declare and isolate dependencies. Dependency declaration manifest needs to have complete and exact declaration of all dependencies. Use dependency isolation tools during execution to ensure no dependencies leak in.
3. Config: A clear segregation of code and config is mandatory. Since code should remain constant across instances but config varies. An applications 'config' is everything that is likely to vary between different environments such as staging, production, development etc. including the following:
• Credentials to external services 
• Pre-deployment values, such as hostname/address for deployment 
• Resource handles to database, Memcached, and other backing services
4. Backing Services: Treat backing services as attached resources. i.e. any service the application consumes over the network as part of its operation/functionality needs to be treated as an attached resource. The code in a 12 factor application does not make distinction between local and third party services. Some common examples of backing services include caching systems such as Memcached, messaging queueing systems such as RabbitMQ, datastore such as Mongodb  or cassandra, metrics gathering services such as New Relic/Dynatrace, SMTP services for outbound email such as Postfix.
5. Build, release, run: Three steps transform a codebase to a deployed application, i.e the build, release and run. Twelve factor applications have a clear segregation of build, release and run stages.
• Conversion of code repo into an executable bundle by compiling binaries, fetching nd packaging dependent libraries and assets, on a specified version of code is commonly known as 'Build'.
• Addition of current or required config to the 'build' produced earlier is referred as release ready to be executed in the designated environment.
• Launch of the application 'release' in an environment is referred as 'run'.
6. Processes: Execute the app as one or more stateless processes. 12 factor apps/processes are stateless and share nothing. Persistence is managed generally via a backing service like a datastore. 
7. Port Binding: Export services via port binding. For example, web apps export HTTP as a service by binding to a port and listen to requests coming on that port. A 12 factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment for creating a web-facing service.
8. Concurrency: Scale out via the process model. Processes are first class citizen in a 12 factor app, having similarities with unix process model of running service daemons. Each process handles their own complexity, threads, events; depending upon technology being used. Share nothing, horizontally partition-able nature of twelve factor applications makes concurrency easy and reliable.  
9. Disposability: Maximise robustness with fast startup and quick graceful shutdown. 12 factor application processes can be started and stopped as required i.e. they need to be disposable anytime and easy to create anytime. It facilitates robustness of production deploys, rapid changes to code/config through new deployments, and fast elastic scaling. 
10. Development and Production Environment Parity: Keep development, staging, and production environment as similar as possible. Minimise time, tool and people differences across environments including code and backing services. This prevents tests passing in lower environment, failing in production.
11. Logs: Logs should be treated as event streams and need to planned from start to enable metrics monitoring and tracking using synthetic monitoring.
12. Admin processes: Run admin or management tasks as one of processes.

Enable and Support a Culture of Seamless Open Collaboration of Code and Teams

Open-source model is a decentralised software development model that encourages open collaboration. A main principle of open-source software development is peer production, with products such as source code, blueprints, and documentation freely available. 

Maintain a service catalog of services and libraries to leverage the power of peer development. Have standard code development, management, design and documentation so that cross team/group collaboration is frictionless and easier.