This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
@Jerry - Yes. We have an EA process blade at the DAIT/DAE level of the framework. In DAD there is an architecture owner role who is expected to work closely with the EAs, and may even be an EA. Then part of this process goal is for the team to align with the architectural direction of the organization.
To help align with the enterprise direction - it is helpful if there is an Enterprise Architecture (EA) function that they set down architectural principles and patterns that can be traced or followed by Product Delivery teams this will help ensure that teams are aligned. We have found that having patterns on wiki has been helpful for teams to align.
@michelle - In the text I've called out API as an access mechanism for applications/systems.
@Klaas - Good points about templates. I fleshed out the description in the update to the decision point. When it comes to components we're trying to squeeze out the concept of small single-purpose components (what we call components) and large-scale domain components.
@Valentin - Good points about architecture guidelines and templates, I have updated the text. Good point about domain components, I've fixed both the diagram and the text.
The v2 update has now been posted and is available for download.
Align with Enterprise Direction à Adopt Common Guidelines: Architecture
“Architecture” is related to all solutions aspects, where “technology” it is important but is not cover all common guidelines needs. Architectural decisions about separation of concerns are more important than technology. In fact, the most important decisions related to software architecture are the ones that make easier changing (!) the technologies. So, my proposal is to put to a more generic description for architecture related guidelines: guidelines related to significant solution decisions, architectural styles, solution adaptiveness … and preferred technologies (consistencies and other reasons).
In the text we have now “architectural vision”, but only technologies are described as example aspects.
About Architectural style guidelines: have at least the same importance as coding guidelines.
Align with Enterprise Direction: Precondition for templates, governance & others
I cannot select templates before knowing the process approach. I will have other templates for a Waterfall or Unified Process or Agile. One of the “strongholds” of resistance to improvement are the traditional process templates: “Agile” teams with Enterprise waterfall templates for example.
Idem, we will have a completely different governance in waterfall or Agile. Real case example: we need to build Gant charts for stakeholders that do not want to use our Agile information radiators, and there is no real useful information in that Gants charts.
More: even in Agile case, we have diverse types of releases, products, etc.
So, I propose to mention also the followings:
Some of the Enterprise Direction could be triggered by external context strategical factors, but all the others are rather part of a common “wisdom”, “architecture”, resulted, emergent from a shared experience and knowledge. Enterprise assets will not exist (or will not be useful) without this sharing process.
Align with Enterprise Direction à Reuse Existing Infrastructure: Domain Components
<<Microservices/domain components. An independently deployable set of functionality, with a well-defined interface, that addresses a cohesive business or technical goal.>>
Imo should be rather <Domain Components (Microservices or others)>. The core of Disciplined Agile is to promote <choice is good> concept. Microservices are only a very particular (trendy!) option of <Domain components> architectural style. I saw too many teams that adopt Microservices without having the real need in their context of all the Ms related decisions. They code and invest too much, just blindly following the examples from Netflix, Amazon, and others. In the same time, similar with Scrum, some companies have an aggressive marketing. Microservices are <Domain components> with a series of choices already made: binary interface, distinct process, etc, etc. For example, Netflix choose to use Microservices because they need to measure and control performance per set of functionalities, so they decide that for their context to allocate a distinct process for a such set. Also, the decision to have asynchronous communication between services introduce huge extra problems and complexity, solved with significant extra-design effort, prohibitive for other smaller companies.
So Microservices cannot be a default, most efficient and agile form of reuse!
Domain Component can be … a default, most efficient and agile form of reuse! Where is some very particular context cases, an example of implementing Domain Components are the Microservices.
"Adopt Common Templates" is probably something no team can avoid in a larger corporate environment.
In my current environment we can get away with only a few of the existing templates, but we always have to deliver a "Feature Complete Sheet" after we declare a feature finished. These are the base for the release notes of the final grand product to our service and support department.
I can imagine in a full Health & Safety (FDA approval) environment, templates are totally mandatory and choosing is not an option. You may want to highlight that.
I feel that "Components" are receiving too little attention. Many companies have basic frameworks and components that achieve certain goals. Not just for UI, but also for logging, health monitoring, hardware abstraction and such. In my experience, UI components are much harder to re-use than those "single function components". In the end, components (near the bottom) and "micro services" (near the top) are the same thing but built on a different paradigm: components run locally, where microservices run remotely. In both cases, my development effort is limited to glueing and validation.
Hope this helps!
Please respond to this with any feedback you may have about the Align with Enterprise Direction process goal.
Thanks in advance.
© 2013-2020 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA