Top Community Contributors
For whom develops systems, a good and integrated toolset is fundamental: Herminio Lourenço
Written by sparxsystems
Managing a Student Project with Enterprise Architect – Part 2
Written by doug rosenberg
What's new with ArchiMate 3.0 & EA v.13?
Written by DT_Sam
Reader's Choice Award Recognizes Sparx Systems For Software Architecture
Written by sparxsystems
Managing a Student Project with Enterprise Architect – Part 3
Written by doug rosenberg
Fast access to each diagram in Enterprise Architect
Written by Dr. Konrad Wieland
EA TFS Connector a new add-in for the Bellekens EA Toolpack
Written by Geert Bellekens
New SysML Book for Enterprise Architect Users
Written by Dr. Konrad Wieland
Requirements are fundamentally important as they are about building the right system.
Yet the failure of requirements is the primary cause of project failure.
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.
However 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.
In 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.
These 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.
Application 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.
In 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
- 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
Sparx 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
At Sparx Systems there are a number of key objectives that are always in the minds of the developers. One is delivering what the end user wants and the other is to exceed end user expectations, by delivering to their needs at an affordable price point. A third objective is to add value by making the end user experience more practical, inclusive and convenient.
These are the reasons why Enterprise Architect is the total modelling and design environment, -adaptable and extensible, providing all that is required by the end user and reducing or eliminating the inconvenience of access to the “external application”. That’s a simple expectation of a modelling tool, and the Sparx Systems interpretation of this expectation puts Enterprise Architect Version 13 in a class of its own.
Kanban was first introduced into Enterprise Architect Version 11. As a key agile process, Kanban is a method for managing knowledge work, with an emphasis on just-in-time delivery. It presents all participants with a full view of the process, from task definition, to delivery to a customer. Because Kanban is a set of practices that can also be implemented in traditional hierarchical bureaucracy, it does not present a threat to the existing culture and can work within different cultures.
In 2015 a Forrester survey found that the customer experience topped priorities for business and technology leaders. Based on these results Forrester forecasts that in 2016, customer experience “will be among the top 10 critical success factors determining who will win and who will fail in the age of the customer.” This is interesting because agile processes embrace change, which translates as the customer’s competitive advantage. Or put another way, the price of survival is to become agile. In recent times Kanban has been applied to the process of developing software-centric solutions in an attempt to ensure that value is delivered to the customer as quickly as possible.
Kanban is an agile entry point that while it does not challenge the culture it can be used to challenge the status quo. However, as an agile practice Kanban can be a cultural “change agent” and lead to Scrum and XP agile practices. Enterprise Architect offers a complete Agile Project Management foundation for the largest to the smallest of projects, supporting mainstream agile delivery frameworks and methods including, SCRUM, RUP, XP, DSDM and Kanban.
Kanban revolves around a visual board for managing work-in-progress and making work flow issues apparent through process definition based on how the work is handled in the team and on stakeholder priorities. A backlog is created in order to keep track of the work and as a basis for setting priorities. The cycle time of the tickets can be measured and used to keep track on improvements.
Enterprise Architect has built-in Kanban diagrams and a number of pre-built workflow patterns that can be used 'as-is' or configured to suit any project or initiative. Because Enterprise Architect is also a sophisticated modeling platform for strategic and business analysis, architecture, design, implementation, testing and deployment, this Kanban facility becomes very powerful. Work items on a Kanban Board can be linked to strategic decisions, business rules, policies, requirements, architecture and design elements and every facility in the development lifecycle.
Agile planning is the assessment of the rate that agile teams can convert customer requirements into deployment ready software, while determining when they will be done. Burn down charts will provide these indicators. With Enterprise Architect burn down charts and time series graphs can be easily created and these are regularly and automatically updated by Enterprise Architect. A sophisticated charting facility is available to create powerful and expressive charts and dashboards, that will provide insights into the Kanban process and enable Product Owners and other team members to monitor performance and determine ways of fine tuning how the team works. There are a range of built-in charts, including bar, pie charts and heat maps, but a team is free to create any number of user-defined charts, which can also be incorporated into team processes and reviews.
As the affordable solution of choice for organisations who want to adopt Agile, including Kanban, Enterprise Architect 13 concantenates potentially siloed projects or sprints and provides assurance against the risk of segregation and ultimate fracturing of visibility across the enterprise, which can be caused by ad-hoc Agile initiatives.
In Enterprise Architect 13, Kanbans can be set at the individual level or project level in a shared model. With the 'My Kanban' feature, individual work can be tracked while the 'Project Kanban' option supports the team.
Projects of any size can benefit from the efficiencies of the flexible and integrated Kanban facility built into the Enterprise Architect core product. The Kanban features in Enterprise Architect are highly configurable and can be altered to suit any team or process, including agile, iterative and incremental, and even waterfall projects. This simple, yet powerful project management approach, creates a team collaboration platform that will result in products, services and solutions being delivered to customers with efficiency and in record time.
Webinar Recording: Introduction to Kanban and Heatmaps (using EA 12.1)
Workflow model patterns have been added, enabling the creation and linking of single or multiple stage Kanban workflows utilizing the Backlog, Iteration and Complete Kanban diagrams to support the existing “Standard type”. Together, these form powerful Kanban workflows, allowing the easy movement of Kanban elements between them. This movement provides the user with a view of the current team resources allocated to the Kanban element, enabling them to see what resource has been assigned, and completion status.
To assist with control of agile sprints, new menu items are available from the Construct Ribbon to search and find all Kanbans in a model. Kanban drawing style can be used showing Type, Status, Version, Priority, Bold Name, Stereotype, Phase, Author, and Truncate with name and Icon.
Work Items can be drawn with a compelling visual style, such as a colored card that can be dragged anywhere in the diagram to change order in a given lane, or from lane to lane, progressing from left to right through the board, representing progress towards value for the customer. The lanes are typically bound to the values of a 'project management aware' property such as status or phase, and as the item is dragged from lane to lane the value of the bound property is automatically changed. If a diagram is linked to a project management property, dragging an element from one lane to another automatically changes the value of the property, to the value that the lane represents.
To review Kanban features supported by Enterprise Architect 13. please visit:
- Enterprise Architect Version 13 Beta web page: Project Management using Kanban
- Enterprise Architect User Guide: Kanban Facilities
"Coming together is a beginning; keeping together is progress; working together is success."
- Henry Ford
Ten years ago, Gartner published the Emerging Technology Hype Cycle Report, and identified “collective intelligence” as a technology that would have “the greatest impact” on business over the following decade. Now in 2016, a convergence of technologies has conspired to create a miasma of complexity so engulfing that there is no alternative but to adapt to it. Old responses to new norms are inadequate. So how is this challenge to be addressed to retain existing market share and build on achieved success?
A recent article “Let Go of What Made Your Company Great” in the Harvard Business Review (HBR) discussing organisational response states that “the appropriate solution to employ depends on the magnitude of the challenge and how much of the organization is affected by the challenge”.
The very organisational structures that sufficed to create success in the past now present the greatest risk to adaptive organisational response to the complexity challenge. The HBR goes on to demonstrate with business examples, that letting go of entrenched thinking requires bringing “the organizational reflex circuitry out of auto-pilot.” A survey on business agility recently reported that almost fifty percent of survey participants blamed opposition based company culture or philosophy for agile failures.
In “Collective Intelligence in Teams and Organizations” a paper by lead author Anita Williams Woolley from MIT, the team explores the ingredients required for the development of collective intelligence and describes collective intelligence as including “a group’s capability to collaborate and coordinate effectively” stating “this is often much more important for group performance than individual ability alone”.
Agile encourages enhanced communication, sharing of information and collaboration. A report in Forbes from 2015 by Steve Denning discusses how “Agile, Scrum and Lean arose as a deliberate response to the problems of hierarchical bureaucracy that is still pervasive in organizations today: falling rates of return on assets and on invested capital, a dispirited workforce, a decline in competitiveness and widespread disruption of existing business models.” In hierarchical models subordinates report upwardly to the bosses. In horizontal agile structures the team focusses on the customer and as Peter Drucker has stated, the single goal of a business is to create a customer.
The collaborative behaviour between self organising, cross functional teams has recognised similarities in swarm intelligence or stigmergy, the stimulation effect that individual effort has in guiding the work of co-workers and the behaviour that creates the shared outcome.
Through the agile software development methodology, the evolution of requirements and solutions supported by the collaboration activity patterns of agile teams is similar to those exhibited in stimergy. Team members are stimulated by the performance that they have achieved and they are also stigmergically stimulated by their environment which, apart from collaboration enabling technologies also includes management support.
Organizational theorist Ikujiro Nonaka suggests that innovation comes from serendipity. Knowledge is not created by information processing, but by “tapping the tacit and often highly subjective insights, intuitions, and hunches of individual employees and making those insights available for testing and use by the company as a whole". He adds “The key to this process is personal commitment, the employees’ sense of identity with the enterprise and its mission.”
Silos are the nemesis of serendipity. Different team members and stakeholders must be able to input information that is relevant to their roles and activities and that is useful to the other members of shared projects. This implies the necessity to capture this information in a model that is available to all team members overcoming their geographical limitation.
The emergence of new ideas, or innovation, through collaboration, has been commented on extensively. A single idea can lead to breakthroughs and competitive advantage and the idea of one person can be used by many others who can make small refinements or improvements to the idea or spark completely new ideas. These in turn become the normal as creativity destroys long accepted convention.
Collaboration is becoming a new enterprise standard. In the face of the challenges being presented by market uncertainty, successful transition to the most effective use of strategic information technology, is a priority for many organisations. Collaboration enables the enterprise to leverage the strengths of all its parts and by harnessing creative energy and increasing the chances of success, while reducing or eliminating process overlap and resource redundancy. The shared awareness of issues promoted through collaboration encourages trust and builds confidence in group stakeholders and synergises the collective response to problem resolution.
The mutual dependency of collaborative culture and Agile approaches, is essential for successful project delivery, which is ultimately decided by the customer. Whether the organisation is large or small, has not yet adopted Agile or is Agile progressive, a handful of factors are critical to success.
In a business environment where innovative disruption is encouraged and fail fast is the short term goal, it is essential that situational change gets a nimble response and to that end, flexibility must be built into planning. The World Development Report 2013 published by the World Bank notes that creative destruction is the mainstay of economic growth. A plan is essential but it is not indispensable and ought to be replaceable when a better idea presents itself. Adaptive schedule planning identifies milestones, but, maintains a flexible approach to get to them, while making allowances for the milestones to change.
The evolutionary development approach is iterative and is accepted practice for Agile software development. Agile development principles are different. Change is accepted and expected and because Agile software developers accept change as a constant, they choose to work in this way. A central tenet of agile teams is that it is okay to fail and to try another method. Collaboration unites individual efforts enabling the team to accomplish goals. Failure is foundational to these efforts, as it provides opportunities for teams to review and re-organise strategies.
The Global Innovation Index (GII) has established itself as a leading reference on innovation and in 2015 published the eighth report titled “Effective Innovation Policies for Development”. This report stated that “Innovative enterprises are shown to be economically more successful than firms that rely on tried and true processes and approaches.” Agile processes embrace change, which translates as the customer’s competitive advantage.
Early delivery is seen as a leading measure of progress and depends on several factors. Frequent releases of working software, to ensure shorter feedback cycles which in turn facilitate collaboration with customers. This development cycle also encourages discussion which reveals the status of development, uncovers problems and identifies ways of implementing solutions, while supporting learning and development of an understanding of the function of the system.
As implied earlier, higher revenue from stepped delivery is supported by Agile development philosophy which also promotes a culture of ‘perpetual beta’ or early and frequent releases. This high frequency iteration allows the customer to provide valuable feedback on a regular basis.
Process improvement underpinned the successful growth of Toyota from its small company genesis to a global auto industry leader, over a relatively short period. Also known as Kaizen, continuous improvement, a lean based manufacturing approach, systematically seeks to achieve incremental changes in processes, in order to improve efficiency and quality.
When change is viewed as an asset within an organisation, survivability and competitiveness are supported and the process of evolving to a future state is a cultural constant for such organizations. In the past, stability was seen as a positive attribute within an organisation and was the bulwark against change, which if possible was to be averted.
Today that strategy has been obliterated. Agile is the adaptability and responsiveness to change that is essential to successfully compete in the new competitive landscape. The iterative approach of customer driven Agile development teams, while reducing the size of the changes related to a software release, also increases the change frequency. Agile processes embrace change, which translates as the customer’s competitive advantage.