Pros of implementing SAFe (Scaled Agile Framework) Lets explore the Pros of SAFe as I see them. In a future article would look at the cons The biggest benefit of adopting SAFe is the opportunity to tap into a relatively lightweight framework that creates efficiency in software development while maintaining the centralized decision-making necessary at the enterprise level. Pros In large organisations with multiple teams and vendors spread across locations, this is far from reality. SAFe has an excellent way of ensuring the teams recognise the dependencies (during PI Planning), discuss and negotiate them, visualise them and plan for them. SAFe is a solid way of engaging Business Stakeholders on a regular basis with the teams. SAFe's PI Planning process (and other mechanisms like PI System Demo, Product Sync etc.) literally force the teams to engage the business stakeholders, customers and even vendors in the Planning process. Business to Business, Business to IT Alignment SAFe events like PI Planning, Product Sync bring together the business stakeholders, the product development teams, shared services teams and enterprise architecture teams into one place. Business and IT - Joint Planning In SAFe, all the teams within a particular group (called an Agile Release Train) start and end their Sprints on the same day. This brings a degree of synchronicity, efficiency and predictability to the delivery across the group. Implementation Roadmap SAFe has a solid, well proven Implementation Roadmap. This is something that SAFe has put together iteratively over many years drawing on experiences, lessons learned from hundreds of implementations. Structuring the Teams Many Agile teams do their best to deliver in a consistent, predictable way. But they are hampered because of the way the teams are structured and created. If Agile teams are created incorrectly - e.g. based on technology or component or location - they end up creating a huge number of Dependencies increasing the effort and the time to market. SAFe has a lot of literature and best practices and strongly emphasises structuring the teams on a feature basis. The framework strongly recommends undertaking a Value Stream Mapping exercise (as part of the Implementation Roadmap) to structure the teams properly and efficiently (with an aim to delivering as independently as possible). Architecture and transition Design Architecture and Architects are sensitive topics within the world of Agility with widely varying opinions in terms of their role in Agile teams. SAFe tries to strike a sensible balance between completely centralised architecture vs completely de-centralised team based Architecture decisions for various reasons (in large organisations there could be a need to decide on certain tools centrally, purchase licenses on a global basis for certain applications / tools to optimise cost or decide on a central database decision etc.) SAFe's mantra is - Intentional Architecture and transition Design. SAFe also appears to provide the right amount of balance between letting teams do their own thing but establishes some guard rails. It also encourages teams to think about architecture somewhat ahead of time with a continuous transition architecture.
Message processing vs stream processing architecture A quick simple diagram differentiation between message processing and stream processing architecture. The stream processing pattern bears many similarities to the message processing pattern that you are familiar with, but in stream processing, the processor looks at one or more streams as a whole, rather than at discrete messages Streams are aggregated, combined and filtered to observe patterns and enrich data. The output of a stream processor is itself a stream, which may consist of filtered or mapped data or events.
Reinforce application security developed on AWS/ Azure - Options Most corporations are adopting a DevSecOps approach - by maximising automation and trying to reduce manual intervention as much as possible. In continuous delivery environment , most companies dont have the resources and probably not possible to have a team out of project to proceed with security test in a continuous delivery approach. When looking for a solution , here are the requirements that you should focus on : Detection of application code vulnerabilities: Cover the entire application Be able to set security rules Ability to perform incremental scans Acceptable false positive rate Detection must not impact application performance anonymization of the name of the applications for the vulnerabilities reported Automation of detection: Integration with Continuous delivery platforms (example: Concourse, Jenkins) Build in case of discovery of vulnerabilities Reporting: Integrate with bug management tools Raising indicators specific to each application in a portal Dont build i think its a mistake, the market is moving towards solutions that are SaaS and most of these companies are building a blackbox type of security solution, buy a market solution and integrate it here is a starter list: 1) Veracode https://www.veracode.com/ 2) Checkmarx https://www.checkmarx.com/ 3) IBM AppScan Entreprise https://www.ibm.com/security/solutions 4) Contrast Security Assess https://www.contrastsecurity.com/interactive-application-security-testing-iast
