INTEGRATED AND OPEN

Let’s face it, systems and software development is complex, so you’re going to have to buy more than one tool. Each tool will probably work fine for its purpose, but eventually you’ll want to integrate information across tools. Point product integrations are brittle, so you’ll want to start with tools that are designed to work together. The CLM tools are a complete suite for defining, developing, testing, and managing software and systems development, all built on a common platform, the Jazz Platform, and released together, so there is no risk of integration breakage.

But what about other tools, such as existing investments or specialized tools for your environment? You want tools that are based on open industry standards, and that are designed to be integrated and extended. Dozens of integrations with the Jazz Platform already exist. You can create additional integrations on your own, or with help from Persistent.

AGILITY AT SCALE

Unless you work for a very small organization, you’ll need more than just basic agile collaboration, planning, and tracking. As systems scale, you might need these features:

• Traceability to requirements and design specifications
• Monitoring for compliance
• Tools that support collaboration and planning/tracking across geographically distributed teams, programs, and portfolios
• Web-based dashboards and reports that display up-to-the-minute status rolled up from multiple organizational levels with the ability to drill down for detail
• A standard process such as the Scaled Agile Framework (SAFe)

The CLM tools support all these capabilities and more.

ADAPTABLE

Effective organizations evolve their process and tool configurations over time. You might need to support formal, agile, and hybrid approaches. You need to adapt to process changes over time, including customizing existing data types and behaviors, and even adding new types and new behaviors. The CLM tools are highly customizable, and support processes that adapt over time.

EASY TO GET STARTED

The easiest way to get started with the CLM tools is with cloud-based previews. Previews are live environments with video walkthroughs. After you preview the products, consider a no-charge cloud or on-premise trial with assistance from Persistent. Note that the CLM tools are packaged with an enterprise-ready web server and database, and extensive guidance is available for installation, configuration, and deployment.

SUMMARY

Select tools that are integrated and extensible, based on open industry standards, and fully support the needs of large distributed organizations.

For more information, see these resources:

1. Preview CLM
2. Persistent’s CE-CLM services
3. Get help from Persistent

The next article in this series discusses specific features of these tools that support Scrum and Lean.

ABOUT PERSISTENT SYSTEMS

Persistent Systems is the IBM partner that develops the CLM tools. We provide expert consultants that assist in agile and SAFe transformations and can help you customize your process and tools to fit your organization’s needs.

The post Agile and SAFe transformation with IBM Rational CLM: Choosing Tools appeared first on Persistent Systems.

For IIoT implementations, one of the first hurdles is at the point where it all starts – the collection of data from the machines, instruments and sensors. (Also, it can be said to end here – with control of actuators and machines!) Most of the machines, especially in small and medium manufacturing enterprises, are not IoT capable yet. Thanks to the previous industrial automation revolution those are equipped with sensors and even programmable devices in the form of Programmable Logic Controllers (PLCs). However, these are still mostly stand-alone setups with zero to local-only connectivity. The Distributed Control Systems (DCS) and Supervisory Control and Data Acquisition (SCADA) systems could be interconnected to form a larger network. But such systems cover only a single plant or factory with no capability to exchange data with the external world. Their integration with the IoT world requires external hardware and software, like a gateway.

Completely replacing such legacy systems with the new age network-enabled systems could be the fastest way to adopt industrial IoT. But the cost and efforts associated with this would be a strong deterrent for widespread adoption. A cheaper and more acceptable approach would be to either upgrade such machines for IoT connectivity or device intermediate mechanisms (like gateways) that could facilitate indirect integration with the IoT world.

This is where the PLCs come into focus again. The most common way to interact with the factory machines is through PLCs. Machine sensors and actuator controls are connected through the PLCs for sense and control operations. Many, if not most, PLCs generally have the ability to communicate with other PLCs, SCADA systems, etc. to form larger control networks as well as provide visibility into overall operations of the manufacturing plant. Plugging in these PLCs into the Industrial IoT will provide the required upgrade path.

Most of the modern PLCs (except the entry level ones) have built-in Ethernet connectivity or could be augmented by using add-on Ethernet communication modules. Many PLC manufacturers employ proprietary protocols within their own ecosystem and this makes direct integration of PLCs from different vendors into a larger control system difficult. This known problem can be solved with the OPC (Open Platform Communication, also known as OLE – Object Linking and Embedding- for Process control) standard based software (client and server) as it enables PLCs from different vendors to communicate with each other.

However, the large population of the PLCs already present in the field, especially in the older industrial setups, do not have even the Ethernet connectivity. They generally have only the standard hardware interfaces or connectivity mechanisms. Getting such PLCs connected into the Industrial IoT is a real challenge because of the plethora of interfaces (RS-232, RS-485, RS-422, Ethernet, etc.) and protocols (Modbus flavours, Ethernet/IP and other proprietary protocols). In some cases, the PLC vendors offer add-on communication modules to enable the network connectivity. In other cases, one may need to use a device that acts as a bridge or a gateway to handle PLC specific communication on one side and the cyber world communication on the other side.

Such gateways are available commercially from many companies (e.g. Kepware, Opto22, Advantech, to name a few and others), with a variety of features and price-points. For a medium to large deployment, this could provide an easy, fast and cost-effective path. For small (and smaller!) setups, however, the gateway costs may start getting closer to the alternative of replacing existing older PLCs. For such cases, it could be worth exploring the option of building custom, low-cost gateways that are capable of just supporting a specific set of PLCs. Considering open-source implementations of OPC standard could be useful here.

Irrespective of the path followed, this first step is very crucial. Only after this, the fuel for IoT – the data from the machines – could be made available for the bigger things. But there is the second big challenge- how to handle the huge volumes of data being generated and where to process it?

Stay tuned for the next article!

The post Industrial IoT – Instrumentation and Connectivity challenges appeared first on Persistent Systems.

The IIoT revolution is enabled by the advances in electronics hardware, network connectivity, data storage, analytics and cloud infrastructure. Cheaper and more powerful hardware is empowering smart sensors, wireless networks and gateways. Ability to carry large data volumes over local or remote networks for storage and processing has enabled analytics. Analytics from diverse data sets in real-time as well as offline, in turn, has opened newer business models and more efficient work-flows. Getting all these ingredients to work together is what makes the whole greater than the sum of the parts.

The overall IIoT adoption started gradually and seems to be accelerating now. Just like all other revolutions, the 4th industrial revolution is also not without its own resistance and challenges from Luddites who would oppose it for various reasons. There are a variety of factors behind its slower than expected adoption rate, ranging from technical to human aspects. Some of the most significant are:

The post Industrial Internet of Things (IIoT) Challenges appeared first on Persistent Systems.

But technologies like BPM and RPA, AI/ML, Big Data, Blockchain, and IoT have the potential to revolutionize the insurance industry, and disruptive newcomers are capitalizing on them. So, will the industry’s long-time players, of all shapes and sizes, be ready to adopt these digital transformation solutions to survive?

Let me focus on two: BPM (business process management) and RPA (robotic process automation). BPM and RPA complement each other to streamline work processes common to the insurance industry. BPM’s strong suite is process management and clearly, insurance is a process-heavy industry. But the challenges in this industry sector are archaic legacy systems. Core systems are on average 20 years old and different systems live across a variety of technology stacks. With lengthy business processes from incident to closure on the claim end, and the ever-growing complexity on the policy side driven by countless coverage variations, the processes are time-consuming and difficult for humans to comprehend.

A BPM tool like Appian makes it easy to implement such complex rules. It breaks down the barriers of the siloed systems to enable enterprise-wide integration. Appian also presents a low-code option to augment features which are time consuming to implement in monolithic systems.

Many of Appian’s insurance customers have already won industry-recognized business and technology awards for their ground-breaking deployments.

RPA, on the other hand, is very good not just at automating monotonous tasks but also the intelligent work processes previously considered only possible with humans. Automation is a game changer for the industry. It improves efficiency and frees up valuable time for business personnel.

One of the early entrants in this market, Blue Prism, provides integration with cognitive and Artificial Intelligence (AI). In an industry which processes and verifies large volumes of documents and images to extract relevant information, these software BOTS get the job done efficiently and effectively.

The end result is that these solutions help settle claims faster and more accurately. They also empower the underwriting process with improved checks and balance.

It’s an exciting time for BPM and RPA tools in the insurance sector, with the opportunity to transform the industry’s experience for not just themselves but also for their policyholders and claimants.

Perhaps BPM and RPA could just be the superheroes the industry needs.

The post Superheroes to the rescue in insurance appeared first on Persistent Systems.

The post Smart India Hackathon 2018 – The Software Edition in Numbers appeared first on Persistent Systems.

A simple question like that incites a wide range of responses from vague like ‘it is about connecting things, gathering data and doing something with it!’ to convinced ones like ‘Oh, it is mostly analytics!’

Would you like to take a pause here and think about your own reply?

What is IoT? Is it data acquisition and control? Is it communication and control? Is it data analysis and machine learning? Or is it applications that make use of these things?

IoT is none of the above individually but all of the above together! It is a great example of the whole being greater than the sum of the parts. In my favorite analogy, an IoT system is comparable to a human being in terms of functionality. One can identify an equivalent of each of the above IoT components in a human body. Further, just like humans work together to achieve bigger things beyond individual capabilities, different IoT systems can collaborate to build complex use cases to improve process efficiency, prevent failures, and enhance safety and convenience. As a result, IoT is slowly manifesting itself everywhere – from our personal and private lives to the infrastructure, manufacturing, energy, safety and security domains.

IoT generates and processes a lot of data. On the other hand, data – streaming and historic, and analysis of it along with machine learning are essential in order to realize the true potential of IoT. Data and IoT are serving as enablers as well as fueling the Digital transformation in various sectors mentioned above. It is no coincidence that we have Data, Digital, and IoT as three key organizational focus areas.

But as said earlier, IoT is not just about data. The end users care about only the complete, end-to-end solutions, not just a set of components of overall IoT. Building a solution involves many components like sensors and actuators, gateways, cloud platforms, visualization tools, mobile and web applications, security, etc. In addition, it is necessary to have the domain expertise related to the field for which the solution is being built. Almost always, creating an IoT solution demands a wide range of complex skill sets and expertise from diverse yet inter-related fields and collaboration between various entities.

At present, such integration and collaboration are easier said than done. The current IoT industry landscape is complicated because of the abundance of players – a large number of competing IoT platforms with similar capabilities, individual specialized components (e.g. analytics), as well as full solution providers. The lack of standards makes integration and interoperability difficult.

The real challenge and fun of IoT is like using kids’ Lego building blocks. Out of the wide variety of IoT building blocks, the possibilities of what IoT solutions one can build is limited only by the imagination. Whatever one may build, it is important to create the full solution.

To conclude, individual viewpoints about what IoT is may differ, but we can certainly agree upon one thing: An IoT solution is not an IoT solution if it is not end-to-end and complete!

The post What is IoT, really? appeared first on Persistent Systems.

It’s not just the Software Edition this time but a Hardware one as well. While that is slated for a little later this year, some serious coding for the finale of the Software Product Development Competition will be held on March 30^th and 31^st, 2018 across 28 nodal centers in cities all over India. A grand total of 1296 teams will be vying for top honors at Smart India Hackathon 2018 as they code solutions for 27 Union Ministries and 17 State Governments for 36 hours straight!

Throwback to Edition I: Smart India Hackathon 2017 team in action

Channeling the potential and talent of technology students from across the country, towards developing viable solutions for real problems in the country, the platform that is Smart India Hackathon is unlike any other.

How does it work?

Step 1: Union Ministries, Departments and State Governments identified key issues within their scope of work that can be addressed through Digital Solutions. From drought prediction to reducing energy wastage in trains to GPS-based dengue risk trackers, this year 340 problem statements were identified. Applications for innovative ideas were opened.

Step 2: An overwhelming 12,047 responses poured in from all over the country.

Step 3: We shortlisted 1296 teams, each consisting of 6 students and 2 mentors industry and/or academia

Step 4: Live trainings on Facebook and open training sessions for students were held in different cities.

Step 5: All of this effort culminates in a grand finale being held in 28 nodal centers spread across the country.

What started out as a simple idea at Persistent Systems quickly turned into a nationwide movement for innovation. Smart India Hackathon will continue to provide a platform for students to take back real-world experiences of how to become entrepreneurs and give early lessons in the start-up space.

We suggest that you keep a look out for some fantastic prototypes that will support the building of Digital India…

More on the Hardware Edition shortly!

The post Back with a Bang – Edition II of Smart India Hackathon appeared first on Persistent Systems.

While implementing Scrum process frameworks typically all the planning is not done at once, rather it occurs at fixed intervals. This fragmented planning gives better control over the project execution and serves to incorporate corrective actions. Availability of historic data plays an important role in the whole process.

Initially in the process Product Owner discusses the high-level scope of release with scrum team. Next step is team decomposes this scope in artefacts called as Epics. Epics are defined as a group of work items by functionality. At this moment, Product Owner gets back to team with prioritization of Epics. The range of prioritization techniques are available at disposal to be used for requirement prioritization. This includes MoSCoW method, Kano Model, Business Value Bases prioritization, relative weighting priority technique, Walking Skeleton, etc. One of the prioritization model, MosCoW method is explained below.

MoSCoW method: MoSCoW method is one of the prioritization technique used in managing requirements. It, when used, consists of dividing requirements in 4 categories, Must have, Should have, Could have, Won’t have.  Must have requirements are critical to be delivered in given release time, to release to be called as a success. Should have are requirements which, are important but not necessary to product release. Difference between must have requirement and could have one is time box. Should have requirements are as important as Must have ones, however not critical in the time line, as there may be a workaround, alternate paths are available.  Could have requirements are mostly stretched goals, or requirements which fall into the improved user experience, at minimum possible cost. Won’t have requirements are the ones, on which all stakeholders agree that those have lowest ROI (Return on Investment), or not have a value from customer’s perspective at that moment time.

Once prioritization of Epics is clear to the team, the team works on estimating Epics at a high level. This is one of the reasons why the entire team needs to be involved in release planning exercise. While in the process of estimating Epics, interdependencies among Epics are mapped. This helps the team to generate an overall picture of the order of execution, dependencies. This data then goes through normalization based on the priority of Epics. High priority Epics are ordered first for early completion, other enable

Epics which catalyze the process of completion of these are scheduled appropriately. Across team, dependencies are marked clearly, and dependent teams are made aware of them. There are multiple varied techniques available for collaborating among multiple agile teams, scaling agile techniques is out of the scope of this discussion. This first pass through Epics ends when all Epics get estimated at a high level, and all dependencies are highlighted and planned for resolution.

Next pass through back-log (at this moment is set of these Epics) is aimed towards deciding and depicting milestones of progress. Important data to contribute to this is team velocity. Velocity is defined as the quantum of work delivered by the team in each fix time interval called sprint, measured by units of estimation. For example, if the unit of estimation is Story Points, velocity is a number of story points delivered by the team in each sprint. So, based on the velocity of the team, and considering first pass output of backlog, the team creates milestones (Based on Epic Completion) which will act as progress indicator through execution. This completes release planning for the team. The outcome of release plan is high level estimated Epics with predicted time for completion associated with each of them. This gives confidence to Product Owner about the realization of product development plan in near-term, and it becomes easy to Product Owner to prepare for customer engagement appropriately.

Below is table#1 that gives the synopsis of the release plan for a team

Table#1: Milestones through project execution

Table#2: Sprint Schedule during the release

Monitoring progress towards release predictability.

After above tables are made, team proceeds through execution of sprint. While progressing project through sprints, scrum master updates information radiators, also updates tables, especially table#2 above to compare the planned execution of scope against actual execution.

Table#3: Sprint Schedule during release execution

If we look at above Table#3: Sprint Schedule during release execution, it has gathered data at end of Sprint #1 and data points to the fact that Story Points delivered at end of Sprint #1 is lesser than those of planed. At this moment, team discusses this issue in retrospective to find out the reason behind it. If corrections are beyond the control of team, product management is involved to take necessary corrective and preventive action. And progress towards release is tracked periodically using this mechanism.

References

#1: State of Scrum survey report: https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2018-state-of-scrum

The post Release planning, and executing in projects that use Scrum appeared first on Persistent Systems.

The answer could be in the concept of “The Sigmoid Curve,” written about by Charles Handy in “The Age of the Paradox.” Imagine the Sigmoid Curve as the curve of an organization or an entire economic region. The curve initially declines in a time of experimenting and learning, then rises in a period of growth and prosperity, and finally declines leading to the end. The key to sustaining a healthy business or a healthy region is to make a transformation to a new curve before the current one is too far in decline.

The traditional healthcare business is an interesting example. Over the last decade, there is significant digitization of health data. Legislation changes challenged the status quo over the traditional fee for service model of healthcare delivery to push for pay for performance models. The notion of care for the population base rather than individual patients started to emerge. Public health and social determinants of health started to play a role in treatment plans. At the same time, fueled by the accelerated pace of genome sequencing, personalized and targeted therapeutics began to emerge rapidly than ever. Various chronic and rare diseases were targeted through personalized genomics as a method of treatment.

During the same period, software and technology advancements brought in a new wave of technology innovations. Artificial Intelligence/Machine learning, Internet of things, blockchain started becoming mainstream.

These tectonic shifts are a move towards a more integrated health ecosystem (A new S curve?) which focuses on comprehensive disease classification that combines information from biomedical-research, public health, and health-care-delivery communities towards advancing knowledge of disease pathogens and improving health. These integrated health ecosystems can be termed as Precision Health Systems. The focus of “precision medicine” is to explore how treatment or prevention approaches can be developed based on the combination of genetic, environmental, and social factors which could be targeted to individuals or populations. Precision medicine and personalized medicine are highly related and genomics plays a big role in both. However, even highly personalized information may or may not lead to improved health outcomes. Moreover, precision medicine approaches may lead to non-personalized interventions that can be used population-wide.

To position themselves to jump to the next business S curve, the healthcare organizations need to not only focus on internal process changes, but also look for appropriate partners to help accelerate the overall transformation journey. Partners who have the same transformation mindset to be able to help accelerate this journey can prove to be vital during the overall journey.

Persistent Systems is fortunate to work with leaders in the healthcare industry as part of some of these transformations. This ranges from public health innovations to healthcare research innovations to build learning health systems, to healthcare interoperability and operational excellence. Our collaboration with Partners Healthcare in Massachusetts is also geared towards an open source platform to fuel precision health systems. My colleagues Rahul, Sawad and many others have written about the changing nature of healthcare and so has our board member Tom Kendra. Our focus on working with partners to fuel innovations also speaks about the transformation mindset of the organization. Our partners small and large along with various innovative start-ups incubated from our partner organizations like eNre, RxHealth and others are only adding fuel to the fire.

We would love to be part of your organizations S curve journey. Feel free to write to me, drop us a note or meet us at HIMSS if you are at the event.

The post Precision Health Systems, The S curve in Healthcare Transformation appeared first on Persistent Systems.

It is extremely critical for any organization to be clear about the reasons why it is planning to adopt Agile. Without a clear business case, the Agile adoption might lose its focus and might result in a pseudo-Agile environment (referred as ‘Scrum-but’).

Following parameters can be considered for developing a Business Case for adopting Agile:

Business Case for Agile Transformation

It is important for any organization to define the parameters on which it would calculate and review its return on investment. Only with clear and precise parameters, Return on Investment (ROI) of Agile Transformation can be identified. The organization can also use collaboration tools like Innovation Games to identify the current pains areas, which can be used while defining parameters.

Following are some of the parameters that can be considered for ROI:

• Change in project delivery timelines
• Value delivered to the customer
• Improvement of team efficiency
• Reduction of waste
• Payback period

As the first step of any Agile transformation, an organization needs to understand where it currently stands from Agile readiness perspective. This helps the organization to know its current state, how well it is prepared to go for Agile, what are gaps it needs to bridge and investment required before it can move to Agile.

Once the teams start implementing Agile, one of the important assessments that they should conduct is Agile current state assessment. This assessment would help them understand how a team is placed on different aspects like Product Ownership, Release Planning, Iteration Planning, Development Practices, Quality Assurance Practices, and Team Cohesiveness etc. This would help the team to identify the gaps in its current implementation of Agile and team can identify a plan to bridge these gaps. The teams should conduct this assessment together (so that they have collective feedback and awareness about improvement aspects) every quarter.

It is essential for an organization to ensure that its Agile adoption is moving in the correct direction and team is not falling into the trough of disillusionment. A project can fall into valley of disillusionment, if it ends up focusing on just the practices but not focusing Agile principals and thus resulting in fractured Agile implementation. An Agile project should have a defined governance model so that the required stakeholders are aware of the progress being achieved since Agile adoption has started.

Based on our analysis, we have observed that these are some of the key attributes used by different individuals/organizations for identifying ROI of Agile:

• Value delivered to the end user/customer
• Achievement of Business Goals
• Reduction in Cycle Time
• Reduction of costs, defects, waste, delays in the organization
• “Break-even point” i.e. the point where the value generated covers the costs incurred on Agile transformation

Agile project management does provide value to the end users if applied correctly. It is important for an organization to define its objectives for adopting Agile very clearly and should measure progress on these objectives periodically. Implementation of Agile methodology with a strong focus on Agile values/principles would definitely provide the desired outcome and can result in greater satisfaction for a customer as well as other stakeholders.

The post Measuring ROI of Agile Transformation appeared first on Persistent Systems.