Tag: business process management

  • Camunda Extends Reach of BPM Platform

    Camunda Extends Reach of BPM Platform

    Camunda, a provider of a business process management (BPM) platform written in Java, this week added support for an open application programming interface (API) to make it easier to integrate its namesake software with applications written in Javascript/Node.js, Python and C#.

    Company CTO Daniel Mayer said at a time when many organizations are investing in digital business transformation initiatives, the latest updates to the Camunda BPM platform adds support for an OpenAPI standard advanced by The Linux Foundation to enable IT organizations to integrate business processes spanning modules created using different programming languages. In the case of Camunda, IT organizations will be able to generate a REST API client using their preferred coding language that can be integrated with the core Camunda BPM platform, he said.

    In addition, Camunda announced that version 7.13 of the Camunda BPM platform will be available in the form of a lightweight distribution, dubbed Camunda BPM Run, that can be deployed as a Docker container to create a standalone engine with no Java or application server knowledge required.

    Camunda has also added support for Camunda’s Optimize 3.0 to provide a unified view of real-time process insights from any data source and the ability to visually track changes across different versions of process models using its Cawemo tool.

    Finally, Camunda has added support for version 1.3 of the Decision Model and Notation (DMN) specification as well as version 1.2 of the Friendly Enough Expression Language (FEEL) defined by The Object Management Group.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations are looking to reduce costs by streamlining business processes. The decision many of them need to make is determining to what degree they want to rely on packaged applications to achieve that goal versus a platform that enables them to create custom business processes. While many rote processes can be automated using packaged applications, Mayer said the Camunda platform makes it possible to create business processes that truly differentiate organizations from rivals. Packaged applications, in contrast, drive organizations to employ the same business processes in the same way.

    Of course, organizations can customize packaged applications. However, at that point, most of them will have embarked on an application development project that would be easier to complete using a platform designed for that purpose, he noted.

    Naturally, there are other platforms for integrating business processes that revolve around graphical user interfaces. Camunda has been making the case for an open source Java-based platform that enables developers to create and deploy custom business processes using best DevOps practices at a much lower total cost. The company also commercially makes available an enterprise edition of its platform. In total, Camunda claims there are now than 100,000 developers participating in the Camunda community.

    It’s too early to determine to what degree organizations will rely on packaged applications versus BPM platforms to drive digital business transformation initiatives. However, given the current economic climate, it’s apparent these projects have never been more urgent.

  • Workflow Automation Poised to Accelerate DevOps

    Workflow Automation Poised to Accelerate DevOps

    Automation is taking the market by storm. Research firm Gartner predicts that by 2020, more than 40% of data science tasks will be automated, and that is just the tip of the iceberg. Businesses are turning to automation to reduce costs, increase productivity and gain a competitive advantage. Add DevOps to the mix and it becomes readily apparent how DevOps teams can benefit by leveraging a little workflow automation. After all, the DevOps process is framed by repeatable workflows, wherein the agile manifesto dictates progress or other frameworks define how change moves through the development and deployment cycles.

    “Most development projects are hindered by numerous manual steps and the lack of defined collaborative communications methodologies, leaving far too much room for error,” said Raj Mehta, CEO of Raj Technologies. “Defining a workflow and bringing automation into the picture could go a long way toward reducing errors.”

    The DevOps community has come to rely on many manual processes and numerous tools to keep the pace of rapid application delivery and change management. Those solutions often have points of failure, where important tasks can slip through the cracks. Even so, many developers are resistant to change and embrace the processes they have already established. Yet, intertwining manual processes with automation and management tools has been demonstrated as rather inefficient, slowing the perception that workflow automation can actually achieve the productivity promises claimed.

    Perhaps the challenge comes from the fact that many DevOps teams require assistance to achieve any type of automation goals. That indicates there may be a lack of qualified professionals to bring forth workflow automation. “You have to crawl before you can run, and that means you must become an expert in designing workflows, before deploying one, or at the very least, turn to an expert,” Mehta noted.

    A workflow is a fundamental process that dictates the steps to achieve a goal. Workflows have been used for centuries by businesses and have become digitized over the last few decades, with numerous workflow tools coming from leading vendors.

    Many technologists may have first encountered the workflow ideology back in the days when Microsoft’s Sharepoint first came on the scene, which offered rudimentary tools for routing content through various steps. Of course, the workflows in use today have become much more complex, requiring designers to not only know how to script actions but also understand the overall goal of those actions.

    That’s a simple truth understood well by Workfront, a Lehi, Utah, based vendor of workflow solutions which is looking to better service various organizations, as well as DevOps professionals, to create workflow automation opportunities. The company’s primary product goes by the name of Workfront as well and uses a platform-based approach for creating workflows that can be integrated across multiple technologies, bringing centralized workflow orchestration to many use cases.

    Tools like Workfront fit well into the automation equation by creating the foundation of workflows. However, most DevOps professionals need more than workflow design to achieve improved automation. Other elements must be considered, such as demand management, resource management, project templates, policies and scripted actions. Efficient workflow tools should also incorporate task lists, collaboration capabilities and reporting.

    Of course, Workfront is only one of many workflow automation companies on the market. Many other vendors are established in the market, with Market News Reports mentioning leaders such as Pegasytems, Tibco Software and Sourcecode Technology Holdings dominating the market.

    HNY Research projects workflow automation market size will grow to $16.58 billion by 2023 from $4.68 billion in 2017, at an estimated CAGR of 23.48%. Key factors such as ease in process with the installation of workflow automation tools, convergence of workflow automation with traditional business processes, focus on streamlining business processes and cost efficiency through workflow automation are driving the workflow automation market.

    “Business leaders must carefully analyze different processes and identify which workflows can automated. Therefore, business leaders should avoid rushing into workflow automation adoption and analyze the various potential use cases and choosing which vendors best fit in their organization,” said Naveen Joshi, founder and CEO of Allerin.

    Many businesses are leveraging workflow solutions on their path to digital transformation and bringing once-manual processes into a world where automation can be applied. While some may argue over the intricacies of digital workflows and how those workflows fit into business process management (BPM), one truth remains evident: The goal is to digitally transform and introduce automation, which in turn indicates robotic process automation (RPA), becomes the next logical step.

    According to Grand View Research, the global RPA market is expected to register a CAGR of 31.1%, from $597.5 million in 2018, driven largely by demand for business process automation via artificial intelligence (AI) and software robots.

    RPA paired with workflow design may prove to bring full digital transformation to DevOps, and potentially grow beyond just a niche in those challenging environments. Workflows, BPM, BPA and RPA are becoming increasingly important to DevOps organizations seeking to lower error rates, boost productivity and improve communications.

    — Frank Ohlhorst

  • Demystifying Crucial Phases of Project Management

    Demystifying Crucial Phases of Project Management

    With competition becoming more intense for development companies, project management is becoming a more integral part of every project. It’s no longer limited to the actual creation of a new project. Now, it’s about planning, communicating, collaborating and analyzing. With so many moving parts, it’s difficult to understand all of the important phases of project management.

    This guide will cover all the phases of project management so you can understand how they apply to your projects in DevOps. Even if you don’t have a background in project management, you’ll be a pro in no time.

    Defining Project Management

    First, we need to articulate exactly what project management is. It’s the discipline of initiating, planning and executing the work of a team to achieve specific goals within a time frame. It involves a lot of interteam collaboration, and it isn’t any single activity.

    Project management experts draw knowledge from areas including human resources, communications, risk management and even accounting. That being said, there are a lot of moving parts that can make project management tricky, particularly with large projects or growing teams. Knowing all of the phases of a project process makes it possible to navigate these areas effectively.

    A project process is any unique action that represents the entire project internal process within DevOps. This is usually decided by the project manager. It might include instructions, procedures, plans or organizational software.

    Understanding the Phases of Project Management

    When you’re talking about the project life cycle, you need to understand the project management phases. Throughout the project life cycle, you should be able to define clear goals. These will include a combination of the following:

    • What will be accomplished?
    • How will you measure what has been accomplished?
    • Who will work on the project?
    • How will you monitor progress?

    Having these questions above in mind will direct the project along its life cycle. Without any clear initiative or direction, you can’t expect team members to know where to go with their tasks. That’s why clear goals are key in the world of DevOps, where every task matters.

    Now that you know the importance of clear goal setting, it’s time to finally define the phases of project management. There are five in total, and they are:

    1. Initiation
    2. Planning
    3. Execution
    4. Performance monitoring
    5. Closure

    Phase 1: Initiation

    This is the beginning of the project. In this phase, you’ll want to define your goals, what the project is exactly, and how it fits into your company goals. One of the biggest pitfalls in the world of development is choosing to start a new project for technology’s sake. While there’s always something to be gained in innovation, avoid falling for shiny-object syndrome. Just because you have new technology doesn’t mean it makes sense as part of your bigger business strategy.

    To make sure you’re choosing the right project for your team, ask the following questions in this phase:

    • Why are you choosing this project now?
    • Is this project realistic?
    • What does the end result look like?

    From there, you’ll need to get approval for the project from higher-ups. This might take some time, so be sure to articulate your goals clearly at this stage so you don’t waste energy. Finally, you or your project manager will create a project initiation document (PID), which is a formal outline of the purpose and requirements of a new project.

    It’s smart to include developers across teams in these initial meetings to ensure they can give guidance about the technical challenges of a new project. Remember, collaboration is key at every stage.

    Phase 2: Planning

    Now that you’ve gotten the green light, it’s time to create a plan of action. This will involve goal setting and job responsibilities for all team members of all levels. Don’t forget about the S.M.A.R.T. goal-setting process to make sure you’re creating goals that are realistic. Remember, smart goals are specific, measurable, attainable, realistic and time-bound by a deadline.

    This is the most vital stage of project management. It’s when you’ll put pen to paper and work out any kinks. Poor planning will reflect itself in every stage after, so take the time to work with teams to decide the best plan of action. Limit your deadlines for every task to 10 days or les to ensure you don’t let obstacles take away from your final product.

    Phase 3: Execution

    The time for planning is over and now it’s time to get down to business. This is exciting because you’ll see your project start to shape itself. Your programmers are busy coding, designers are building graphics and managers are creating progress reports.

    Don’t forget to update your higher-ups during this process, even with small changes. Regular updates are necessary to make sure everything is progressing according to schedule. Conduct weekly meetings to make sure everyone knows how the entire team is progressing as well as their own next steps. A project management software is valuable at this stage.

    Phase 4: Project Performance

    Now that the project is completed, it’s time to reflect on your success. Did everything align with your original goals? Did you meet your deadlines? Think about your objectives, your deliverables, your cost,and the performance of the project. How did all of these things measure up?

    You’ll base your future project plans on the success of your analysis at this stage. Even though the project is officially done, that doesn’t mean there isn’t still more to learn. Also, don’t forget about preparing maintenance for your software going forward. You might need a program like Amazon CloudWatch – monitoring and logging service to continue to learn about the success of your project into the future.

    Phase 5: Closure

    Your project is completed and your analysis is coming to a close. It’s time to follow-up on any final pieces and close the door on your project for good. This is also known as the post-mortem phase because it’s when you’ll decide your key takeaways and stop progressing.

     

    Project managers will meet together to decide key players, project performance, and deadline analysis. How can you learn from the events of the past few days or weeks to grow during your next project? Don’t overlook this stage. It’s important to reflect on what worked and what didn’t. If something didn’t work out the way it was planning, talk about it.

     

    Finally, host a team meeting to talk about how the project went as a group. You might have a different perspective than those under you, and it’s important that everyone feels heard. Take team member feedback seriously so you can learn from it for next time.

    Manage Projects Successfully

    In the world of DevOps, project management plays a lead role. Don’t overlook any stage in the process as not being necessary. It’s important to have a well-rounded, thoughtful approach to leadership. There is no perfect way to lead a group in big projects, but you can use every phrase to carefully tackle new challenges and grow your team strengths.

     

    When you practice these stages above, they’ll come naturally. You’ll notice each stage leading gently into the next, and that’s how you make a business that’s ready for anything. Every project manager will experience some level of failure, but learn how to roll with the punches and keep moving forward.

    — Wendy Dessler

  • IT Governance at DevOps Speed: Time to Shift Gears

    IT Governance at DevOps Speed: Time to Shift Gears

    Technology plays an incredibly important role in the idea economy, where business innovation is dependent on the software that powers the business. Speed and agility in IT are key to a competitive advantage in this modern economy, in which small startups with disruptive ideas are competing with well-established enterprises and industries. Consider how Uber and Airbnb are challenging taxis, rental car companies and hotels, all based on the power of an idea and software. Yet, traditional enterprise IT struggles to deliver at the speed business demands.

    Have you ever heard a business leader say, “Our IT teams are extremely responsive and very fast”? The typical response is quite the opposite. IT is commonly viewed as a bottleneck to business innovation and, in many organizations, the business simply avoids IT and instead creates some form of shadow IT.

    IT Governance, the Old Way

    The principles and practices of DevOps creates the potential for faster delivery and higher quality. However, one of the largest sources of friction is the traditional focus on IT projects and project governance. Consider this definition of a project from the Project Management Institute:

    “A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

    Given that projects can be expensive investments, and because of limited resources, enterprises justifiably carefully prioritize and plan which ideas and initiatives should be approved.

    Faced with limited resources, enterprises expend significant effort to prioritize, optimize and fund only the most important projects. But no matter how well-intended, this governance approach also struggles to respond to the speed and velocity required in the idea economy. Indeed, the typical portfolio-planning and project-management approach is often an underlying cause of dysfunctional IT behaviors such as excessive requirements, throw-it-over-the-wall deployments and questionable quality—none of which are pleasant.

    Consider how the business approaches user stories and requirements management. In a traditional, project-driven world in which the project is a one-time opportunity, businesses often are given an exhaustive list of ‘must have’ features in their user stories. This behavior is understandable—given the ‘feast or famine’ nature project, funding businesses need to make sure their future needs are included, even if the need isn’t immediate.

    Sadly, this introduces both technical debt and excess complexity from the very beginning. Especially, when you consider that only a fraction of those ‘must have’ requirements will ever be actually used. In fact, a recent IEEE paper noted that 28 percent to 45 percent of software features often go unused.

    Consider how “project success” is typically measured. Project teams typically are evaluated on their ability to deliver on time and on budget, along with other various quality and satisfaction measures. The emphasis on schedule and cost can drive sub-optimal decisions, as deadlines and cost pressures loom. As a result, testing is often abbreviated, as the schedule compresses. Sometimes the scope is reduced to conform to the deadline. This routinely leads to challenged releases in which the service desk is left holding the bag, which ultimately degrades trust and teamwork.

    After the project is completed, the project team often redeploys to other projects, depending on demand for specific skills. The accumulated knowledge and wisdom of the team is lost and there is no further incentive to invest in automation or process improvements because the team has disbanded.

    The DevOps Shift

    DevOps is a very different approach that requires rethinking how work is funded and governed. Fundamentally, a DevOps team is charged with delivering small, high-quality releases, very quickly. The team embraces fast feedback to remove bottlenecks and waste and utilizes relentless automation to make tasks repeatable and efficient. Given that the team will deliver dozens or more releases per year, it is incentivized very differently from the traditional “project” team. The DevOps team often “owns” the application in Development, Test and Production, and has a shared accountability for the value it delivers. The team reduces handoffs and delays and implement small, frequent changes in response to business demand, customer feedback and system performance.

    The friction of traditional governance needs to be addressed using DevOps to enable the enterprise to thrive. One of the ways to remove the governance friction is a paradigm shift from projects as described above to products. It is vital to focus on value and business results along with employee and customer satisfaction. The key difference is that a product is funded for the long haul:

    • A product team delivers ongoing value and the business can count on improvements to meet market demand.
    • A product team does not form and disband depending on funding.
    • A product team is focused on delivering value through the product and will naturally enhance and improve their processes. CIOs and senior leaders need to consider using the Product model as an alternative way to fund and govern their initiatives.

    I’ve talked with several IT leaders who are exploring how to evolve the concept of the traditional project toward a longer-term product orientation. Some organizations explicitly make the change to products, and others are taking a more evolutionary approach. Regardless of the path, the need to evolve the funding model is clear.

    Consider how product governance is different from projects. The product team, in partnership with the business, is funded for a sufficient period of time (year, half-year, perhaps quarter) depending on the business needs. The product team then delivers fast releases of business-driven innovation and rapidly updates the system based on feedback from continuously assessing the product. As the team remains intact, it is able to learn and improve while also accelerating delivery. Additionally, because the product team is able to deliver quickly, the incentive to overload releases with “nice to have” features is greatly reduced.

    Here’s how the mindset is different:

    Project                                                                         Product

    Short time frame                                                   Long term commitment

    Limited funding                                                     Predictable funding over time

    Team disbands                                                      Team owns the product and results

    No incentive to automate                                   Automation improves quality and speed

    Incentives based on schedule/budget            Incentives based business value

    This does not mean there won’t be projects in the future, but there will be a combination of products and projects in most large enterprises. Most likely, we will see projects will be the way new products are proposed, evaluated and conceived. However, once the product is launched, the product team then will operate under a product model and mindset.

     

    About the Author/John Jeremiah

    John Jeremiah_HeadshotJohn Jeremiah leads the Digital Research Team with the HP Software Applications Delivery Management team. He is a software professional with over 20 years of experience including a variety of leadership roles with the U.S. Navy, IT consulting and Fortune 500 IT organizations. His previous roles span from application developer, project and program manager, Director of Testing Services, and Delivery Process and Methodology Director. Prior to joining HP, he was director of Testing Services and Project Delivery Services for Thrivent Financial for Lutherans, where he led the adoption of CMMI Maturity Level 3 process framework.

  • Bonitasoft makes business process management more agile with open source

    Bonitasoft makes business process management more agile with open source

    Organizations embrace DevOps for a variety of reasons, but one of the core value propositions is speed. DevOps enables business to build, test, deploy and update applications more quickly than without DevOps. With so many quickly-moving parts, though, organizations also need tools to help keep track of it all like a business process management platform.

    Bonitasoft developed its business process management platform—Bonita BPM 7—to facilitate the creation of engaging, process-based applications. It was also important, however, that the applications be able to adapt in real-time to changing business requirements. The latest release is an open source version that represents a strategic shift for Bonitasoft—a somewhat inevitable evolution to leverage the same practices and principles in designing and maintaining the platform as the platform is intended to manage.

    “We’ve embarked on a new mission to create solutions that empower developers to build applications that support continuous change,” Bonitasoft CEO and co-founder Miguel Valdes Faura said in a press release statement. “To win in today’s competitive climate, you need to be able to adapt to change quickly and continually improve your business processes and the applications that support them. Bonita BPM 7 is the first solution leveraging the power of open source and BPM process-based applications that meets the demands of today’s business requirements.”

    Bonita BPM 7 is built on a popular and widely used open source BPM solution. Developers can create processes in Bonita BPM 7 using the BPMN 2.0 standard, and can seamlessly connect with existing third-party systems such as CRM and ERP systems. Bonita BPM 7 builds on the open source foundation, though, with more extensible frameworks, and a powerful connector builder tool to enable developers to freely code their own graphical components and REST APIs.

    The “secret sauce” of BPM 7 is the way Bonitasoft segregates business logic from the data and user interfaces. The separation makes it easier to introduce changes in real-time. Developers can perform maintenance or push updates to the user interface independently of the business workflow and without taking the application offline.

    According to Bonitasoft, the key benefits of Bonita BPM 7 include the following:

    • Speed – Developers can build applications faster, improving developer productivity
    • Freedom – Developers can easily build what business really wants, and companies can maintain their applications easier and more affordably with live updates
    • Adoption – Development teams can empower their users with more accessible, engaging and usable applications, boosting competitive advantage

    “Bonita BPM 7 represents a real convergence between the world of the ‘BPM app’ and traditional enterprise software,” Valdes Faura said. “It gives developers the freedom to easily code and extend the system whenever they hit the limit with its native features. Plus, the platform is built for change, so developers and business users can apply changes, updates and improvements over time – creating what we call ‘living applications’ that live and breathe and grow along with your business.”

    As developers develop faster and DevOps enables organizations to push and update applications more rapidly the need for tools and platforms to monitor and manage things grows. By leveraging open source software Bonita BPM 7 follows a successful strategy already employed by companies like Github and CloudBees. If you’re looking for a business process management platform you should check out Bonita BPM 7.