Enterprise Architect version 15.2

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

Displaying items by tag: devops

The need for speed

With the recent passing of General Chuck Yeager as well as the beginning of 2021, I thought it might be a good time to reflect on the never ending quest for speed. General Yeager, of course, was the man who broke the sound barrier in his Bell X-1 aircraft on October 14, 1947.

It’s always worthwhile trying to do things faster and better — that’s what drives progress and innovation. In the software industry we’re talking about a less death-defying problem than the airspeed pioneers faced, but an important one nonetheless: how fast we can develop software?

 

1 Chuck Yeager X 1 color

Chuck Yeager and the Bell X-1 that broke the sound barrier, Glamorous Glennis

Our primary mission at Parallel Agile is to help companies accelerate the development of high-quality systems — so projects are both faster and cheaper, without sacrificing quality. (Yes, it really can be done!). Maybe in a few years we’ll look back at today’s software engineering techniques with similar nostalgia as we’d look at 1940s subsonic aircraft design.

What makes software slow?

Let’s start by looking at what’s holding a typical software project back from getting itself done quickly:

 

2 speed limiters

Many factors can slow down your project — here are a few chronic causes of software getting done slowly

So, what makes software slow? First of all, the common perception that it’s not possible to develop with bigger teams because of communication overhead. Second, typical agile development processes tend to favor feedback over planning, resulting in under-planned systems that spend lots of time on retrospectives and refactoring. Additional factors relate to a general state-of-the-practice of most code being written by hand — often driven by a general mistrust of generated code. Everything from fundamental database access functions to basic UI functionality is most often still coded by hand. Add in modern requirements for data privacy and database security (things that often don’t fit well into 2 week sprints) and you’ve got lots of time spent writing code the hard way — labor-intensive development. Finally, with CI/CD we’ve got deployment pipelines that get executed on a continuous basis.

How do you go supersonic with your dev process?

So, what’s the right stuff that can help you accelerate your software project? Parallel Agile as a development process, and CodeBot as its primary enabler, offer a different vision for software engineering where the speed limiters shown above are systematically removed. You can remove some of the speed limiters and go faster than before, but it’s really removing the whole set of forced-slowdown practices that yields the most dramatic results.

3 removing speed limits

If your project is being slowed down by anything on the list above, we can help.

Project development is organized by scenario In the first place, from a process perspective, with Parallel Agile you organize your project with a developer responsible for each scenario (hence the “Parallel” part of PA).

 

4 one developer per scenario

It’s simple: assign a developer to each scenario (scale as needed)

You don’t have to work in small teams (although you still can if you prefer to). Communication overhead is reduced by virtue of a shared (executable) domain model among developers. Rather than time slicing development into 2 week sprints (with time on each end for planning and retrospectives), you can allow each use case to evolve along a simplified spiral model starting with proof of concept, moving on to minimum viable product (MVP) and then through as many optimization cycles as needed.

5 spiral

Each scenario (aka use case) evolves asynchronously along it’s own spiral model

How CodeBot shatters the team-size barrier

Back when General Yeager was pioneering flight faster than the speed of sound, it was a dangerous activity because aircraft tended to shake apart due to excessive vibration at Mach 1. But advances in aerodynamics eventually overcame the sound barrier.

What’s the analogy to large team software development? Consider the case where several use case scenarios make use of the same domain object. If you assign a different developer to each scenario, each of those developers needs a common understanding of the data structure (JSON) that comprises that domain object. If you allow each scenario to evolve independently you’ve got a communication and coordination problem to deal with. Having the domain model documented on a UML diagram helps, but it isn’t enough.

We discovered the solution to this problem during the early years of our research into parallel development — to be specific, between 2014 and 2016. During that time we were experimenting with an early version of CodeBot that generated a database access API (and API documentation) from a domain model. We discovered that our developers were able to collaborate easily, even when some were working on mobile apps and others working on web apps. Our first test project involved 47 graduate students working in parallel, on a location-based advertising system (LBA).

We also found that most of the evolution of domain class schema happened during Proof of Concept, and that using a NoSQL database allowed multiple developers to evolve the schema independently. Later, we added switchable schema validation to CodeBot, allowing more free-wheeling changes during prototyping but then providing the ability to lock things down as we moved forward into MVP. We also made updated API docs immediately available online. This ability to rapidly generate a new API along with updated API documentation as changes happen in the shared domain model allows projects to be staffed elastically — your team can be “right-sized” to the problem at hand rather than constrained by pre-imposed limits. This lets you go a lot faster.

6 executable domain model 1

CodeBot turns your domain model into a working database, accessible by a REST API, in moments

Inside the use cases: Getting WIRED

We’ve found that it makes sense to organize the project along use case boundaries, with larger teams of developers each working their own use case, interfacing to a shared domain-driven database API (or event-based model, etc). But what happens inside the use cases? Do we need to do a lot of formal use case modeling? Not necessarily…

We think the fastest way to proceed within each use case is to wireframe up the screens that participate in the use case, connect the wireframes to the executable domain model, and then code generate the screens. Think of this as Wireframe-driven, Iterative, Rapid, Enterprise-ready Development (WIRED).

7 wireframe MVC

You might recognize a Model-View-Controller pattern in CodeBot’s generated UI code

We use the CodeBot full-stack application generator to do this code generation for us. In fact, CodeBot is optimized towards PA’s highly iterative process. In short, you can use CodeBot to generate working user interface code (e.g. React JS) from wireframes, where the UI navigation or user flow is driven from a UML state machine, and the screens connect to the database using the API. It all happens automatically, and it happens very quickly with CodeBot UX.

 

8 wireframe to map

CodeBot UX is the fastest way to get from an EA wireframe to a running web application

 

Being Enterprise-ready means Security is baked in

To be Enterprise-ready in 2021, you need to deal with requirements for data privacy.  This means avoiding threats from hackers, making your applications fully security-aware, and implementing best practices for secure development. From an app development standpoint, dealing with security concerns slows you down, and complicates hiring and staffing your project as not all developers are expert at security-related issues.

9 access control

CodeBot-generated APIs come with an Access Control Layer that helps prevent unauthorized access

Over the last year we’ve spent massive amounts of effort building security infrastructure into CodeBot. Capabilities like server-side registration and login automatically generated as part of the API, fully-tokenized (JWT) access, and Role Based Access Control (RBAC) are built-in to the database access API as an access control layer when the model is code generated. The resulting time and cost savings all accrue to your benefit. And if you consider the cost of getting your database hacked…it’s a pretty easy decision to make.

Rapid Iterations come with auto-deployment

To fully realize the promise of agile, feedback-driven development, you need to iterate the project’s use cases quickly to gain immediate feedback from clients. CodeBot enables this capability through automatic deployment of both the UI and the back-end database/API.

10 deployment

With CodeBot UX you go from a UML model to a running (and hosted) web app in under 5 minutes

At present, CodeBot can generate and deploy a securely hosted full-stack web application from a UML model in approximately 4 minutes. This capability makes it quick and easy for each use case to evolve through its spiral model and to quickly test in the context of a deployed system.

So, how fast do you want to go?

Are you content with the pace of small-team, short-sprint agile development, or would you like to deploy a larger team on a more complex problem and get the project done more quickly? Are you happy with the pace of writing database access code by hand, and wrapping the common database functions in a REST API, by hand? Is it quick and easy to turn a set of wireframes into fully-functional user interface code, where the screens are automatically linked to the database? Are you happy with the pace of adding Security to your applications? And finally, does it take you longer than 4-minutes to build and deploy a fully-working application? If you’d like to get your projects done faster and less expensively, but without sacrificing quality… contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..

Published in White Papers

How to create a full-stack React Bootstrap UI in under 10 minutes

A tutorial and reference on designing a complete web application and generating it with CodeBot UX

by Matt Stephens, Parallel Agile

This article was originally published here: https://medium.com/parallel-agile-blog/create-a-full-stack-react-bootstrap-ui-in-under-10-minutes-d0eec3077618

CodeBot from Parallel Agile is a full-stack application generator, which can also host your generated application in the cloud. Give CodeBot a domain model and UI wireframes, and it’ll create:

  • a React web UI
  • a MongoDB database
  • a Node/Express.js REST API, optionally secured using JWT
  • API client libraries — currently Java and JavaScript, with other languages set to be released soon, including C#, Swift, TypeScript
  • JSON Schema
  • Swagger/OpenAPI docs

We have more targets, platforms, architectures and languages on the way, but that’s plenty to get started with!

To whet your appetite, here’s a quick CodeBot video that shows a project being turned into a generated UI:

tutorial1

 

Getting Started

To get started designing your new application, you’ll need:

  • a copy of Enterprise Architect (EA)  to create the domain model and wireframes
  • a CodeBot account from Parallel Agile

At the time of writing, the generated React UI isn’t in full release, but it’s available under Early Access for customers with a CodeBot license (to gain access, please email us)

There’s also a handy series of step-by-step CodeBot 101 videos that show how to get everything installed and set up — so I won’t repeat those details here:

VSRADS Example

In this article I’ll walk through the a much-simplified version of the “VSRADS” model shown in the above example video.

VSRADS stands for “Very Short Range Air Defence System” — it’s basically a mosquito zapper. It listens for the high-pitched whine of a mosquito flying by, calculates its position and trajectory, and zaps it with a low-frequency laser.

Our example project is a state machine simulator… given a series of states, a web page is generated to represent each one; and the state machine itself is turned into the navigation “user flow” between pages — i.e. the routes.

So let’s get started!

Step 1: Create a project with 3 top-level packages

Create a new, blank project in EA, and give it the following 3 packages (via “Add View” in the right-click menu):

tutorial2

 

This will become a familiar pattern… the “three amigos” for defining a new full-stack project

When the model is generated later, the elements in each of these packages will contribute to the generated application, as follows:

tutorial3

  • Each wireframe is turned into a React web page
  • The navigation state machine is turned into a set of routes
  • Each domain class (created in the Domain Model package) is turned into a MongoDB collection and REST API create/read/update/delete endpoint

Step 2: Draw the domain model

Under “Domain Model”, create a class diagram and populate it with some domain classes.

The complete VSRADS domain model looks like this:

 tutorial4

For this example you could just create a subset — just be sure to include Simulation Run, as we’ll be linking it to the UI and database.

Step 3: Design the UI Navigation

The idea is that you design individual screens as wireframes, and link them together via a “user flow” or navigation diagram; in this case we’ll draw the user flow as a state machine:

  • Each state represents a screen or page
  • Each transition (the arrows linking the states together) represents a navigation route

Navigation routes are triggered by things like clicking a link, or submitting a form — “create” or “update” actions.

To introduce the idea, here’s a “hello world” kind of example:

 tutorial5

 

Each generated page will be given its own URI (/login, /view_products etc) so can be individually bookmarked. However, the “Initial” pseudo-state is used to determine which page is displayed by default— the “navigation root” or home page.

Back to VSRADS though… this is a more complex state machine:

 tutorial6

 

Each transition arrow has been given a trigger, which is shown as a label in the diagram. To add a trigger, double-click on the transition:

 tutorial7

 

In EA, you don’t need to select the trigger type etc, you can just enter a name, to keep it simple.

The name needs to match up with the component name in the wireframe, e.g. a button called “Target Identified” — you’ll see some examples of this in the next section.

Usually, the trigger name is also prefixed with an event type, such as on click: or on create: . However, “on click” is the default, so can be omitted.

It’s also worth noting, if the button name is the same as the target page, then CodeBot will figure it out, so you then don’t even need to give the transition a name.

The following event prefixes are supported:

  • on click— e.g. “on click: Login”
  • on create — e.g. “on create: Target”
  • on update — e.g. “on update: Target”

The events all take place in the “source page”, i.e. the page that the transition arrow points from. The trigger will, as you’d expect, result in the app navigating to the “target page”.

The create and update events are triggered when a form is submitted in the “source page”.

Now that you have the overall website or application designed, it’s a good time to create a wireframe for each one.

Step 4: Design the wireframes

EA has a UI wireframe designer built-in. Because the wireframes are fully integrated into the UML model, you can link together wireframe elements, classes, states and other elements… so everything fits together in the generated project.

The VSRADS model has 8 wireframes in total. For this article we’ll focus on two of them, Set Up Simulation (the start page), and Listening for Mosquitoes.

Creating a Wireframe

Right-click on the Wireframes package and choose New Diagram:

tutorial8

In the new wireframe, you need to create a top-level frame which serves as the page-size boundary. This may seem less relevant for websites, but will become important when CodeBot also generates other platforms such as mobile apps. (New feature coming soon!!)

 tutorial9

Always add a “Client Area” to represent the page boundary, and fit all the wireframe components inside it

Next, add some components to the page!

  tutorial10a

Currently with the Early Access release, CodeBot recognises a subset of all the available components. So for now, be sure to only add from the Controls and Website Controls tool palettes.

Position and size the components to match your page design. CodeBot will translate this into a responsive website layout; e.g. it’ll detect grids of label/textfield pairs, alignment of individual labels or buttons, etc.

You can also supply hints to influence how the page is generated. In EA, this is done via tagged values — you can find these on the Tags tab in the Properties panel:

 tutorial11

In the above screenshot, the Set up Simulation title has been given a tag called css class, with the value h1 (“Heading 1”). To add more than one CSS class, separate them with spaces.

The generated website uses the popular React-Bootstrap project, meaning you can specify any “Bootstrap-standard” CSS classes here.

Another useful tag is variant. This conforms to the Bootstrap 4 colour variants:

 tutorial12

For example, the Run Simulation button is given the “primary” variant (the exact case doesn’t matter) via a tagged value, so will be rendered in the page with a solid-blue background:

 tutorial13

In this way, it’s possible to adhere to Bootstrap’s design language—the “primary” variant represents the main or default action, etc.

For future platforms even if they don’t use Bootstrap, CodeBot will adapt the same “Bootstrappy” tagged values to the target platform, so you’ll only have to draw the wireframes once in order to get a generated website, mobile app, desktop app etc.

Just to illustrate another page in the same UX design, here’s the Listening for Mosquitoes wireframe:

 tutorial14

The Image component can display any image type normally supported in web browsers (jpeg, gif, png). Just include a url tag with the complete URL where the image can be loaded from.

Step 5: Define actions on UI elements

In the previous screenshot, the Run Simulation button also has a tag called action, with the value create.

As long as the button resides in a container panel with form components (text fields etc), when the button is clicked, the form will be submitted to the generated REST API. What happens next depends on the value of the action tag:

  • create (create a new record in the database)
  • update (update the current record)

The form elements do need to be linked to a particular domain class, though; so let’s do that next.

Step 6: Link UI elements to the domain model

There are two ways to associate UI elements with a particular domain class:

  1. Use the domain tag
  2. Draw a dependency relationship from the UI element to the domain class

Which one you use is entirely up to you; the effect on the generated code is exactly the same. It’s more of a stylistic choice, as some people appreciate the visual aspect of seeing a link on the diagram, while others prefer the detail to be tucked away.

Domain tag

Click on the form component you’d like to link, and add a tag as follows:

tutorial 16a

The domain tagged value uses the form:

Class Name.attribute name

e.g. Simulation Run (the domain class), a dot, then name (the attribute name).

As a time saver, you can also just add the domain class name to the parent container panel:

 tutorial17a

The “child” form components are then auto-linked to the domain attributes, by matching each component name with an attribute name.

Once this linking-up is done, then when the generated form is submitted, it’ll automatically call the correct REST API endpoint for that domain class.

Dependency arrow

As an alternative to the domain tag, simply drag the relevant domain class from the package explorer onto the wireframe. Then draw a dependency arrow from the container panel to the class:

 tutorial17

You can also link the individual text fields to the class, if preferred.

To emphasize again, this has exactly the same effect as using the domain class; which you use is just a personal preference.

 

Step 7: Generate the application

If you have the CodeBot add-in installed in EA, right-click on the root (“Model”) package in the package browser. Then choose:

Specialize > Parallel Agile > Generate Project

If you can’t run the add-in for any reason (e.g. you’re on a Mac using a Windows VM), another way to run CodeBot is as follows:

  1. Make sure you’ve selected the root (“Model”) package, then from EA’s ribbon menu, choose:
    Publish > Export-XML -> Export XML for Current Package
  2. Login into the CodeBot Web Console at parallelagile.net, and choose Upload XMI:

 tutorial18

tutorial19

CodeBot will detect that the model contains wireframes, and automatically generate a Bootstrap-React project. You can find it in the downloaded zipfile, in the UX/React folder.

 

Step 8: Run the React app!

You can optionally elect the generated application to be hosted — just make sure the “Publish to our cloud service” checkbox in the above screenshot is ticked.

In this case, CodeBot will automatically build the React app, and then publish the full website, REST API and database to our secure cloud service.

To access the hosted website, click the blue Visit Website button (visible in the above screenshot).

The Set up Simulation page will load in a separate tab:

 tutorial20

 

When you enter some form details and click Run Simulation, the following series of events take place:

  1. Due to the action tag and the linked domain class, the React app submits the form to the REST API
  2. The REST API validates the form data against the generated JSON Schema (based on the domain class and attributes), then creates the new record in the MongoDB database
  3. Due to the on create: Run Simulation trigger on the navigation state machine, the React app will detect that a “create” just happened linked to the Run Simulation button. So (as the trigger is on a transition), the browser navigates to the next page, Listening for Mosquitoes:

 tutorial21

In closing…

CodeBot UX radically shortens the iterative feedback loop when developing new software. When domain modeling, you can now quickly create a working prototype, use the prototype to elicit new or changed requirements, feed the updates back into the model, rinse and repeat…

… often several times in the same workshop session, with the customer or domain expert right there in the room (or on the same Zoom call).

CodeBot UX is available now for Early Access customers. To request access, please email us at: This email address is being protected from spambots. You need JavaScript enabled to view it. — we’ll welcome your feedback!

Published in Tutorials

sdtimes 100In an in-depth and illuminating interview with Sparx Systems Founder and CEO Geoffrey Sparks, Alexandra Weber Morales from SD Times identified several key aspects surrounding the company's continued growth in the DevOps space.

 

Geoffrey illustrated how Enterprise Architect provides a solid platform for the delivery and support of new applications, services, and technologies, by encouraging and facilitation of increased productivity between development (Dev) and IT operations (Ops). The Sparx CEO also explained the importance of UML as the established standard for software modeling.

 

"Within those organizations that are undergoing digital transformation
to improve operational efficiencies (many of whom are Sparx Systems
customers), there is a prevalence of UML tools deployed to manage application
delivery, a process which relies implicitly on code quality assurance."

- Geoffrey Sparks, CEO & Founder, Sparx Systems

 

Read the full article in PDF - available on the Sparx Systems website here

Visit SD Times website here

Read More about Sparx Systems and DevOps here

 

 

 

 

Published in News

SDTDevOpsInterview

In this month's edition of SD Times, reporter Alexandra Weber Morales has interviewed Sparx Systems CEO, Geoffrey Sparks about the prevalence of UML in DevOps culture.

Morales, who originally profiled Sparx Systems over 10 years ago, reconnected again to ask about the Sparx Systems' approach to DevOps, digital transformation and how UML can assist in automating aspects of the delivery pipeline.

'UML is the established standard for software modeling - anyone sketching a simple use case is modeling in UML.' 

- Geoffrey Sparks

 

The article can be read in its entirety at: http://sdtimes.com/uml-makes-devops-driven-digital-transformation-possible

The interview is also published in the March edition of SD Times. 

Published in News

sdtimes 100Regular contributor to SD Times, Lisa Morgan, has published an in-depth piece titled 'Navigating the endless ALM river', she investigates alternative solutions to some of the premium offerings within the marketplace.

Lisa investigates the latest thinking within this space, gathering insight from senior subject matter experts, who describe contemporary thinking in this fast-paced sector.

Sparx Systems Enterprise Architect is included within a list of highly-valued software solutions that facilitate continuous delivery, deployment and integration processes.

We encourage you to read the full article at the SD Times website.

Published in News
Tuesday, 29 November 2016 22:47

Requirements for Digital Transformation

Requirements are fundamentally important as they are about building the right system.

Yet the failure of requirements is the primary cause of project failure.

cogs triptych 844x160

How many times do we forget passwords AND user names? This is a clear example of the risk associated with the reliability of the human memory and associated human error. Let's consider the management of the myriad detail accumulated throughout the requirements planning process and the steps of Eliciting, Documenting, Analysing and Communicating. Oh, and let's not forget Tracking, Validating and Verifying!

So spare a thought for the Business Analyst, whose whole focus is on capturing requirements, to ensure successful project outcomes. Or to put it another way, the task of translating the needs, wants and expectations, of all user stakeholders, into technical language for the developers and others, to ensure that they - the users - are are going to get the functionality, that they need, want and expect from a system. This is not a petty task and it can take months. Meanwhile, there is the probability, due to complexity, that not all of the requirements are going to be addressed because of a number of factors, not least, their having been lost or forgotten.

Requirements Coques2 175x100However if effectively managed, requirements identification and supporting traceability improves the overall project outcome, simply because time will be saved, less money will be spent, and most importantly, the customer will be happier.

The Requirements management process has seen much change in the past 20 years and two of the most obvious are the involvement of the customer in all phases of the process and that the requirements process itself is now dynamically linked into an agile culture of continuous integration and delivery. The increase in software defined business, is driving the growth and importance of application delivery within encumbent enterprise and with ever more startups disrupting their industries, enterprise needs greater levels of automation to compete and to deliver quality, quicker than competitors.

In the past Requirements were captured in hand written paper documents, which in time, were augmented with spreadsheets and word documents. The rigour of the process left space for improvement. Today, requirements associated material is held in a central repository and updates are visible to all stakeholders. Enterprise Architect can capture all of the different information that records requirements information, be it from Word, Excel, Visio, handwritten notes, video or audio.

Requirements Coques3 175x100In the past Requirements was an isolated process that had built in “wait” or handover periods before being consumed by the other phases of the project life cycle. Today these gaps are closed with automation and requirements are integrated across the development life cycle, with many other functions. The end result is less time to delivery.

Organisational cultures of resistance to change, identified by a bulwark of divisional and departmental silos and a reluctance to co-operate, increased the risk of failure for the change process. Today, technology based collaborative platforms are increasingly being adopted as they are inclusive, breaking open silos, empowering stakeholders and drawing them together.

The progress of development projects lacked transparency for most key stakeholders, right to the point when business took delivery. Whatever visibility the stakeholders had, was gathered from assumptions, rather than from objective data. Today, key stakeholders form an integral part of the development team and have access to progress charts and dashboard metrics.

In the past, the management of shareholder supported organisations held tightly to the overarching goal of ensuring change was minimised or avoided, so as to maintain the value of their shares. Today the digital imperative, as opposed to the business imperative, says be prepared to change, or risk oblivion.

Requirements Coques 175x100These examples are a reflection of the changes in the Requirements Management process, which in the development model of today, supports iterative requirements gathering and continuous delivery of software. It has become an Agile practice approach, being adopted to address the challenge of digital transformation. This collaborative, iteration based business lifecycle, between requirements and stakeholders, has given rise to DevOps, a strategy for managing continuous change.

Enterprise Architect is unique in its ability to support Requirements throughout the development lifecycle and to deliver the benefits of the Agile practice approach. Requirements can be defined in the model, or imported from other tools including Visio.

Recently, through agreement with IIBA, Sparx Systems is in the process of developing the Enterprise Architect Guide to BABOK Implementation. Through the power of this collaborative, visual modeling platform, the extension provides the Business Analyst with a fully augmented BABOK user experience.

On March 29, 2017, the public Beta launch of Tools & Techniques for BABOK Guide v3 was announced - please visit the Sparx Systems website for more details.

Published in Sparx Insights
Tuesday, 01 November 2016 02:47

DevOps and ALM: Bridging Business and IT Cultures

AgilDevops illu 400x400Application Lifecycle Management (ALM) can move IT and Business to a position of congruency and shift IT from application thinking to process (and service) thinking and in Business, from service to IT. The gulf between Business and IT exists on a relationship from a time past, when there was little contact between the two parties following a commission from Business to IT for services and/or products.

Before the availability of ALM, the window on the progress of development projects lacked transparency for most managers, right to the point when business took delivery. Whatever visibility the managers had, was gathered from assumptions rather than from objective data.

Sparx Systems attended the Gartner Enterprise Architecture Summit in National Harbor during May 2016 where Enterprise Architecture was reviewed as a “catalyst for Digital Tranformation.” and two “big” challenges were identified, as the transformation moves forward. These were, managing the connections within complex ecosystems of communications, partners, platforms, services and technologies and working with New Development methodologies such as Agile, DevOps and Continuous Delivery.

ALM makes IT development visible to upper management and reinforces the requirements of Business to demonstrate Governance, Risk Management and Compliance. On a competitive level it assists in the reduction of development costs, increases innovation and effectively supports change management. As a business process for the management of end to end software development ALM promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales.

Between IT and Business, ALM creates and supports a bridge which embodies a set of processes and methods, including software development, operations, and services, to enhance communication and collaboration between departments. It also aligns the business, development and operations capabilities of the organization, by providing the ability to integrate different tools used and the activities performed within each.

While this establishes a culture of more frequent software builds, tests and releases, the pressure to manage application delivery is growing ,as is the complexity. The need to co-ordinate and automate the process of delivering these projects, with collaborative planning and reporting activities has become critical. Sparx Systems recognises that this requirement makes ALM processes essential to the delivery of worlds best development practices.

 

"DevOps is a culture that supports improvements
in the software development lifecycle through
automation, best practice and collaboration."

 

Tight coupling of the stages of the application lifecycle is a key to increasing productivity in application development and establishing traceability and accountability across multiple processes, locations and tool types, in the stages of development and delivery. This completeness of functionality leads to increased quality, reduces time to market and promotes a culture of business agility. By coordinating activity and facilitating communication, ALM provides real time transparency and traceability, proactive change management and error mitigation.

We hear a lot about cultural change in the discussions about DevOps. We also hear a lot about people. Not so much about enabling technology. There is an accepted notion that DevOps is about drawing together people in DEVelopment and people in OPerations with the goal of shortening delivery time through the elimination of constraints that naturally exist between functional silos.

DevOps is a culture that supports improvements in the software development lifecycle through automation, best practice and collaboration. DevOps is about changing culture and the responsibility for this lies with executive management. To realise a cultural change of automation, best practice and collaboration, is to expose the organisation to DevOps benefits,- agility and productivity. As a key enabler of DevOps, Continuous Delivery supports automation of software development, testing and deployment which are in turn supported by agile planning and execution tools.

sd times alm article madison mooreIn an article by Madison Martin, published recently in SD Times, the impact that DevOps and Agile are having on application lifecycle management (ALM). She states that “Those looking to refine their application life cycle are sifting through the marketplace to find the right tool—one that will give their company agile feature functionality and help them move toward a more continuous way of working. A business can no longer look at just the planning and the building of software; they have to monitor every step in between to make sure the software delivered meets the expectations of the user.”

ALM is accepted as the management of end to end software development and as a business process it promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales. Due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

The ALM tools market has seen a continuous evolution over the greater part of the last decade. The change is demonstrated by various benchmarks conducted by Gartner. As recently as July 2016 Gartner has announced their decision to retire “the ADLM MQ and focus on a new MQ for Agile planning and execution tools.” The leading reason cited for this decision is “Shifts in the market due to DevOps.”

Between 2012 and 2013 Gartner blogged that work had begun on the update to the Magic Quadrant for ALM stating “We are subtly shifting our terminology for the market from Application Lifecycle Management to Application Development Lifecycle Management. We feel this is a more accurate depiction of what the tools in this space are focused on.”

In 2008 Gartner published the “Marketscope for Application Lifecycle Management”. This document was described ALM as the practices, processes and tools that aid in the application management lifecycle, specifically the workflow of producing or maintaining an application. This document identified a number of key capabilities that an ALM offering should include. These capabilities have been listed later in this document.

 

Sparx Systems ALM

In 2015 Sparx Systems was named in the 2015 SD Times 100 for its excellence in the ALM and Development Tools category. When using separate tools in development, there can be a lack of integration between the tools used in each phase of the process and due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

However, when using Enterprise Architect, an integration of all the key features of ALM is provided in an “out of the box” tool set, which uses a single repository as the common data source. Within the integrated Enterprise Architect project workspace, you can view and update artifacts with version control, code review, and continuous integration tools. This is the level of functionality that defines Enterprise Architect as a leading ALM solution.


Key ALM Capabilities

  • Requirements definition and management
  • Change and configuration management
  • Agile project planning
  • Work item management
  • Quality management, including defect management
  • Reporting
  • Workflow
  • Integration to version management
  • Support for wikis and collaboration
  • Integration to other ALM tools

This is the first of a series of related articles on DevOps and ALM

Published in Sparx Insights

LOGO SDTimesSparx Systems' Enterprise Architect has been featured in a recently published SD Times article, Online and Social Media Editor Madison Moore identifies the emerging influence of DevOps and Agile within the ALM domain... and the software that is supporting Enterprises to master their future evolution.

 

"Market disruptions such as mobile and the Internet of Things (IoT), as well as the digital and omnichannel trend as a whole, have contributed to this evolution of ALM. Once these disruptions happen in areas like DevOps and agile, they change the way companies build their applications."

 

Enterprise Architect has been identified as a platform that is "... a comprehensive team-based modeling environment that helps organizations analyze, design and construct reliable, well-understood systems." The feature rich toolset supports project teams to communicate and capture essential business information, to transform the Enterprise into a standards compliant entity, therfore realizing the potential for interoperability and future agility.

 

To read the full article by Madison Moore, please visit the SD Times website 

Published in News