[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: on SAFe® for Lean Enterprises, Full SAFe
answerring Ken's question about SAFe, please, find my notes on SAFe® for Lean Enterprises, Full SAFe [ http://www.scaledagileframework.com/# ] . Sorry, this is a long text.
1. A Lean Enterprise might need Epic Owners at the enterprise portfolio level – I never saw this.
2. A Value Stream illustration – quite artificial because Epics do not constitute any business value as well as Enabler
3. Enterprise Architect and Lean Portfolio Manager come from out of the blue - in real enterprise, there are a lot of works should be done before a portfolio may be created. Particularly, in the business realm of a company, executives and special ‘Architects of Business’ define business capabilities, their compositions, Capability Deployment Plans, Business Transformation Plans for Target Operating Model, and only then Portfolios (what to do) are setup along the Business Transformation Plans. Provided infographic is good for IT only, not for the Enterprise. If you are interested in finding what is Architecture of Business (not TOGAF’s Business Architecture), you can look at architectureofbusiness.com
4. A group of Solution Arch/Eng-Solution Manager-STE should set the Governing Function, first of all, which is absent in the image. Also, there should be ‘privacy’ and ‘security’ references
5. Solution Context relates to Customer in only 1/3 of its scope. The other 2/3 of context are: a) laws, business rules, regulations and corporate policies (governance) AND technology platforms (in-house and outsourced/in Cloud).
6. I do see a problem in the order of LARGE SOLUTION and PROGRAMME. If assume that the order displayed is right, the Solution Arch/Eng should be either an Enterprise Architect (by TOGAF) or an Architect of Business ( a business person) – this role should define portfolio, programmes and products to be involved in the future solution. IT’s Solution Arch/Eng is not called at this stage. What is a Solution Manager – I do not know (it may be a Business Executive in whose department the work should be done, e.g. COO, HR Head, Marketing Head, etc.)
7. The IT’s Solution Arch/Eng appear at the level of Propgramme (this is what I do for the living). Business requirements appear at this level as well. They are divided from the Programme level to the Project level. At this moment the final decision (initiated at the LARGE SOLUTION stage) about outsourcing is made. The objectives of each project are defined, reviewed and approved by the Programme Manager, Product Managers, Business Solution Manager (stakeholders), Enterprise Architect or Architect of Business. An overall technical architectural solution is created and approved.
8. A DevOps layer has to be positioned only now. By this time, the company should know how many teams will participate in the solution, what the approved overall technical architectural solution is, what are the integrated objectives for each project are, where the DevOps teams should deliver their outcomes – in to production or in the testing staging area.
9. In the TEAM level, we have to clear distinguish between the Business Product Manager and the product manager of the product/outcome of each DevOps team. Depending on the size of the Programmme: if there is one project/team – a one-time architectural governance review of the outcome is conducted before the deployment; if there are several projects/teams build the solution – an architectural governance review of the outcome is conducted before the deployment into test-area and after each integration/regression test.
10. Overall, SAF overemphasises the value of DevOps and Agility. Their diagram may be efficient for small companies only. The enterprise level agility is required for agility to the market; the DevOps in such context have #16. Yes, DevOps can speed-up development, but nothing has principally changed from the IBM Rational RUP time – developers continue making design decisions at the level of code. In the presence of Microservices and a shift from pure development to assembly of Microservices, an ‘independence’ of a DevOps team decreases if it uses any foreign Microservices – from another LOB or another company. Someone, not a developer, has to make sure (due diligence) that the use of particular (each) Microservice does not generate a new risk for the business od the company where the developer works.
- Michael
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]