Business Rules Management System (BRMS)

BRMS are expert systems designed to manage your rules and business logic. Instead of keeping your rules—the guidelines by which you make critical business decisions—in the form of application code in software systems, you have abstracted that logic and put it into a system specifically designed for managing rules with NO CODE.

With a BRMS, you are building, modeling and testing your rules in this separate system from start to finish. This allows you to concentrate on the differentiating features and user experiences of your applications without worrying about the logic in the code.

The Bank I am currently working uses Corticon from Progress as the Business Rule Engine. We develop business rules and deploy the end points as Restful API’s.

By adopting a BRMS, Business and IT teams can collaborate regarding business rule changes and shorten development time. Business people can be brought into the mix as they can now take on the responsibility of directly updating the business logic. This will in turn require less IT resource because your business analysts will not have to wait for development teams to update your current rules.

BRMS tools like Corticon can support millions of transactions, all of which can be configured using a spreadsheet-like modeling tool that just about any competent business analyst could master.

The value proposition of BRMS is two-fold. First, your business can write down all of its business rules in one place, and business experts can review them and make sure they make sense. Second, because BRMS is a self-contained system, separate from the main software application, people in the organization do not have to be programmers to write and update business rules, or to apply them to the functioning of the main application.



What is blockchain?

Blockchain is a way of organizing data so that transactions can be verified and recorded through the consensus of all parties involved.  The system is founded on the concept of an authoritative ledger that records events. 

While current data systems hold that ledger in a single, centralized location, a blockchain requires each individual participant – or node – to hold a copy of the record.  Any potential changes to the record must be compared against each and every node before being approved, which strengthens security and reduces the likelihood of unauthorized changes.

For example, let’s say that Joe is being tried in court for stealing Pauline’s purse.  Typically, a court reporter would be employed to type out everything that Joe says into a court record.  If Joe admits to the crime, this transcript of the proceedings will function as irrefutable proof that he confessed.   This document is kept in the court’s offices, under lock and key.

But Joe’s friend Bob wants to help Joe out by eliminating the record of his crime.  Bob steals a copy of the key, opens the court’s office, erases Joe’s confession, and leaves. 

Since there’s no other official record of Joe’s admission, there court cannot prove that Joe ever admitted to stealing the purse.

This is how the current generation of data repositories work.  Bob wasn’t authorized by the court to have a key to the centralized location where the data lived, yet he gained access anyway and used it improperly.  Joe’s crime has been erased from history, as far as the legal system is concerned.

Now, let’s say Joe is up to his old tricks again, and goes out on the street to snatch Jessica’s purse.  But this time, there are ten bystanders with smartphones, and each bystander independently records the deed.  Now there are ten records of what Joe has done, and no easy way for Bob to change every single bystander’s video in exactly the same manner to make it look like Joe is innocent.

The only way the record of this event could be changed is if all the bystanders come together and decide, as a group, to alter each copy of the video in precisely the same way.  That is unlikely to happen.

If all the bystanders agree as a collective system that the data should continue exist in its current format, the event becomes locked in time as a fact that has happened.  It is an entry in the ledger: a fixed point that cannot be changed. 

Once the chapter has been closed on this event, it is known as a “block.”  The block is redistributed to each node, which re-validates the change and agrees to edit its version of the ledger to include this new event.

Every subsequent potential change to the data must be validated against this block before it can be added to the “chain” of events.  This is accomplished through sophisticated matching algorithms that verify the party’s right to access or alter the data.

When it comes to financial matters, or a virtual currency like Bitcoin, it’s easy to see why this is important.  Every participant in a transaction must agree that a payment took place at a certain time for a certain amount, or the transaction is void. 

All transactions depend on the ones that went before it.  If Joe empties his account and has a $0 balance, he cannot then write a $20 check to Bob from that same account an hour later.  Neither Bob, Bob’s bank, nor Joe’s bank will agree that the transaction is valid once the check bounces.




Microservices Have Macro Effect

Microservices are not a type of technology, but rather an approach to IT architecture. By using a suite of tools like APIs, containers and cloud, microservices break applications into simple, discrete services.

APIs are at the heart of technology based partnerships, which is why microservices are so critical to any business looking to build partnerships at scale.


Read More

Hyperledger Project - Fabric, Sawtooth Lake. What's all this?

The Hyperledger Project is managed by the Linux Foundation and NOT by IBM – which is key because the Project is meant to incubate more than just IBM’s offering. IBM initially contributed what was then called ‘Open Blockchain’ and is now called ‘Fabric’, and arguably that is the biggest / highest profile project.


Read More

IT Supplier Management

Spurred by technology advances and a lower cost delivery model, outsourcing of IT functions across various industries continues unabated.  Many IT resources find themselves assuming dual responsibilities for technical subject matter expertise and supplier management - with supplier management as an evolving new role.

Suppliers also find themselves taking on more end-to-end responsibilities in Managed Services Models, which include both service delivery and program management. In many cases, suppliers are placed in positions of control for end-to-end processes. As a natural consequence, many suppliers have more autonomy and are self-incentivized to drive process improvements.

Companies have increasing come to the realization that the success of an outsourcing program lies largely on their supplier management. But an inherent challenge exists. Closer relationship with suppliers is generally beneficial for day-to-day operations. Too close of a supplier relationship will affect objectivity and potentially, breeds ineffective supplier management. Fulfilling contract obligations or Key Performance Indicators (KPIs) may then be at risk.

There is certainly a growing awareness that good governance can make or break an outsourcing deal. Understanding and adequately enforcing key aspects of supplier governance will significantly reduce risks. Effective governance can stop value leakage and improve outcomes. Supplier management has become increasingly important although many organizations continue to under-invest in this critical activity.

Involving the Procurement group in this role can be a solution to this challenge.  The CIO can be well served with a strong, capable and independent Procurement partner to play the “bad guy” role in supplier management. In particular Procurement can help to manage supplier risk across the enterprise since then are working across the organization with other categories such as HR, marketing, legal, operations and manufacturing,

The Procurement group can rise to the challenge by transforming itself in three key areas.

Recruit, develop and retain the right people

  • Recruit business oriented people with strong soft skills who can operate across multiple disciplines and develop strong relationship with IT stakeholders.

    1. Implement program to train existing staff with the right skills to be able to operate in the new collaborative environment. Training needs to include supplier management playbook training, analytical, business case development and soft-skill training e.g. presentation, facilitation, conflict management, emotional intelligence.

    2. Develop good career path through supplier management track and interesting strategic opportunities to retain and motivate Procurement staff.

Develop and implement strong processes, including risk management

  • Develop a strong governance model with defined roles and responsibilities between the firm’s management structure and suppliers. Escalation paths should be clearly defined with specific contacts documented.

  • Drive the agendas for Quarterly Business Reviews as opposed to relying on supplier-led status updates. Ensure that performance issues are raised and addressed. QBR (too often I have to sit through QBR where supplier reported all the good news and the status where all green, while I know there had been performance issues with those particular suppliers)

  • Segment suppliers into Tier 1 and Tier 2 to provide appropriate focus on the critical suppliers. In most cases, because management of Tier 1 suppliers requires significantly more effort, Tier 1 should be limited to 5-10 suppliers.

    1. Implement a periodic supplier auditing process. Annual site visits to Tier 1 suppliers should be included to ensure compliance.

    2. Ensure there are sufficient contracting languages to protect the firm’s data and systems. Also, a robust business continuity plan should be in place.

    3. Evaluate and manage supplier risk at the Statement of Work, order or contract amendment level i.e. evaluate supplier risk by each SOW and not just at the supplier level. Since there will be examples the you can unknowingly giving high risk work to low risk suppliers, therefore inadvertently making them high risk without the appropriate evaluation

  • Manage financial risk is an area that Procurement had demonstrated successes: My procurement teams have taken over the management of invoices for selected suppliers (telecom, data, software, hardware etc…) on behalf of IT department. The procurement teams have been able to apply their knowledge to the contracts to make sure invoices are accurate. Historically we have discovered inaccurate and duplicate invoice, from my experiences there were some suppliers have error rate in the 40-50% range. For this service instead of asking senior service manager (manager/director level) to review 500-1000 pages of invoices against 10 different contracts per month, we relied on a handful analyst to review and validate invoices against inventories and performance levels.

    • Develop supplier management playbook and train the Procurement team to monitor consistent high quality and service delivery against the playbook.

    • Assess current Procurement services and determine service realignment necessary to meet the needs of the CIO and IT. For example, expand capacity without increasing head count by reducing “bad busy” work and increasing “good busy” work.

Leverage on Procurement technology

Procurement also needs enabling technology. For examples:

  • Procure-to-Pay process, e.g. Ariba or Coupa, can be used to efficiently match purchase orders with invoices.

  • Risk management tools, e.g. Hiperos or Bravo, can manage risk at the transaction level.

As IT evolves to become a major client of the Procurement area, Procurement must be ready to transform itself to become a supportive IT partner. Procurement will need to realign its services to provide the available bandwidth and produce consistent and high quality service level to ensure a trusted relationship is achieved. Procurement will need to develop stronger capabilities in the supplier management area to support the expanding needs of IT. This will require strong sponsorship from the CIO and CPO to ensure a comprehensive implementation. The CIO and the CPO play pivotal roles to closely collaborate to cement the relationship between their respective IT and Procurement areas.

Credit : This article first appeared in CIO Review magazine.


Agile development and Scrum

Somebody asked me the What's the difference between Agile and Scrum. Let's first understand the basics of Agile and scrum.

What is Agile development?

  • Agile software development is a methodology that is followed to overcome issues associated with the traditional waterfall development.

  • In Agile development, you follow an iterative approach where the entire software project is completed in iterative phases. Each iteration delivers an incremental working version of the application.

  • Users continually evaluate each working version / iteration of the product, and provide feedback to the development team which the developers incorporate into subsequent versions of the product.

  • This approach provides the opportunity to account for changing business realities and also minimize large scale project/product-failure risk that can sometimes happen when using the Waterfall approach to product development.

  • Agile still uses some of the keys steps associated with Waterfall development in each iteration i.e. analyze, build, and test.

What is the business context for Agile Development?

The Agile methodology is typically used in scenarios where:

  • The requirements or details of outcomes are not very clear at the outset.

  • Business needs are changing rapidly and /or are continually evolving.

  • Where testing the feasibility of an available technology to solve a problem is critical

  • Where funds to develop the product may be made available incrementally based on the proven feasibility of the product.

  • Where bringing a version of the product to market as soon as possible is more critical than having all the bells and whistles.

How does Scrum fit into Agile Development?

While the Agile methodology can be applied to product development not only in the software industry but in other industries as well, Scrum is specific to software development.

Scrum is not a methodology. It simply provides structure, discipline and a framework for Agile development. The whole project is made up of a series of Sprints or Sprint Cycles (1 to n) where each Sprint is of the same duration. If ‘time’ is denoted by T, then T1 = T2 = T3 =… Tn. Sprints could be anywhere between 2 to 4 weeks. Sprints shorter than 2 weeks are not ideal and are used less frequently. At the end of each Sprint, a functional / working piece of software is produced that the users can actually test.

The diagram below illustrates the use of Scrum in Agile development.

Write here...

Key characteristics of Scrum

  • Scrum does not have a detailed series of steps or guidelines instructing how you go about software development.

  • Scrum does not have team leaders or sub-teams; it is just one cross-functional team where everyone is involved with the project from start to finish. The team includes Users, Stakeholders, Developers, the Scrum Master, the Product Owner.

  • There are 3 roles in Scrum – the Scrum Master, the Product Owner, the Team – note the conspicuous absence of a Project Manager.

  • Self-organizing teams are vital to Scrum i.e. people who are creative and disciplined at the same time and who do not need to be ‘managed’.

  • Scrum is a series of sprints. Each sprint can last anywhere from 2 to 4 weeks (recommended). A sprint is a complete mini-software development cycle (analyze, build, and test phase) . At the end of each sprint, the customer gets a working version of the product with new/additional functionality as compared to the previous sprint. The customer / users test the product and provide feedback to the team.

  • The developers and other technical staff in the team are usually highly experienced and understand both technology and business.

Key Steps in Scrum

The key steps in a Sprint a.k.a. the single basic unit/cycle of development in Scrum are:

STEP 1: Sprint Planning Session

  • Product Owner tells the Team what s/he wants in the Sprint. S/he picks these items from the Product Backlog.

  • The Product Backlog is a list of high level requirements.

  • Team decides what they can commit to.

  • Committed items become the Sprint Backlog – this is frozen and cannot change during the Sprint.

STEP 2: Sprint

  • The period when the team works on building the features identified in the Sprint Backlog for that sprint.

  • Daily Scrum sessions are held to review issues / problems / roadblocks / progress / commitments.

  • The Sprint Burn Down chart is updated each day to show progress / completion of items. The team reviews this daily to understand where and how effort needs to be expended.

  • The Sprint must end on time whether all items/tasks are completed or not.

STEP 3: Product Release (Incremental Release)

  • Release a working version of the product with the features committed to as part of the Sprint.

STEP 4: Sprint Review Meeting

  • Review work completed and not completed versus committed items for the Sprint.

  • Present work to stakeholders as a demo.

STEP 5: Sprint Retrospective

  • Team members review the sprint.

  • Discuss what worked well and what needs improvement.

  • Basically a self corrective session (lessons learned) to incorporate process improvements in preparation for the next Sprint.

So we can say Agile is just a philosophy and Scrum is an implementation of that philosophy.