Devops - Business Proces Management
Contents & topics PM
PM by my personal experiences
Transforming the way of working is a goal on its own. At least that is my personal experiences.
I don´t believe that it is the intention, only not knowing better options to achieve change eliminating unsatisfying dillemma´s.
The one that is dropped first is: "Business"
Too fast .. previous
| Reference || Topic || Squad |
| Intro PM ||PM by my personal experiences ||01.01 |
| Align ||Business Alignment. ||02.01 |
| LCM ||Process Life Cycle mangement. ||03.01 |
| secure ||Security (business: logic - data). ||04.01 |
| computer ||Using machines, using computers. ||05.01 |
| What next ||Following steps. ||06.00 |
| ||Ongoing to do it ||06.02 |
| uncontrol ||Unhappy on what is going on. ||07.01 |
| expect ||Expectations Project management. ||08.01 |
| critics ||Critism Project management. ||09.01 |
| ict PMs ||ICT project management. ||10.01 |
| Agile fate ||Agile or optimizing work. ||11.01 |
| experience ||Customer Journey. ||12.00 |
- 2020 week:26
- Reordering content with alignment to the new CSS.
- 2019 week:16
- This chapter picked some old pictures and put in two new references.
- Having to do: what is usefull from old pages, what to added.
Undestanding the needs of an orgnanisation and doing things in line wiht that is a neverending story of misunderstanding.
Speaking a common language that everybody understands is the first thing ususally missing.
Project management Generic
The primary challenge of project management is to achieve all of the project goals within the given constraints.
This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, quality and budget.
Project management Generic
There is a big market for management advice. A generic starter:
The ideal skill set, the Talent Triangle, is a combination of technical, leadership, and strategic and business management expertise.
Process Life Cycle mangement.
Processes are changing when the needs of an organisations are changing or the customers and / or suppliers are changing.
The change in time is a certaintity.
Tools like software being used in supporting the organsisation also have to change.
Software Life Cycle mangement.
Every enviroment has his omn approach on the Life Cycle Management of hardware, operating system, tools - middleware , business applications.
The confusion on the meaning of "the application" is mentioned seperately. The consequence is that is impacting the release management in several ways
There are many dependicies between those.
Changing the OS layer can impact the behavior of tools - middleware causing unexpected undesirable results at the business applications
Changing the tools - middleware layer can cause unexpected undesirable results at the business applications
Needing new features within tools middelware for development for the business it would the best thing to do to change the acceptance (regression testing) and production environmet as first steps after the proof of the installation setup in a infrastructural environment.
That is not the Develop Test Acceptance Production order of the business applications.
Anlytics determing and really understanding what is to change is a very nasty activity full of bias beliefs and expectations.
Security (business: logic - data).
Risk management and security policies are not very well accepted activities as strategy and tactic. They are however high level business requirements by regulations and can´t be ignored
Who is the CSO?
Security of the assets of the business is too often seen as something technical where no accountability exist within the business
Actions by the ICT department pretending to be in security control
Make the business responsible for the security guideline. See ICT staff as enablers data processor not as data controller (GDPR)
Realisation details IAM
When doing user access management instead of Information Access Management (IAM) the access of business assets by service - and high privileged accounts are getting lost
Important business information assets are left vulnerable at the technology layer in many ways.
Design and implement security access for tools middleware
. Dot that in alignment with the well know user access management approach.
Business logic (code) and (information) are important assets. They are to be governed, data governance for the information.
The operational area is a well known area. The challenge is in improving operational business processes using analytics.
Process Innovation, stable operations
Seeing the operational environment completely isolated from innovation request underpinned by analytics will result in blocking processes and/or innovations.
See the data warehouse data lake as their physical representations.
A solution for in time availablity of resources in the logistical chain.
With "just in time" JIT delivery there will be no need for storing. The concept is Streaming data (lambda architecture).
Copying information to another location is called "datawarehousing" modernized "data lakes".
Historical there is no security concept access included, although is should be present.
The datawarehouse concept is based on the assumption NO information will brought back to operations.
That makes no sense (see dwh data lake).
Using machines, using computers.
Machines are no humans, computers are no humans. The "Artifical Intelligence" hype is misunderstood as would machines computers replace humans ethical and emotical decisions.
As easy scapegoat for bad automated decisions the machines are easy to blame. The better question is who (human) made that decision of an automated machine would always be without failures.
The meaning of "The Application".
What does somebody really meain by the word "the application".
The answer is in Who onWhat When. For most people a computer application is just a black box offering results on input.
Within ICT it is less obvious, we have:
- hardware (physical components, the box)
- operating system (being programs, code)
- tools - middleware (being programs, code)
- business logic (being programs, code) - data (information)
The word is an adjective on what is used on. Each of the higher order one can be seen as being an application of the former.
Confusion is problematic
Hardware, operation system, anything else: "the application".
Business "the application": that is only business logic - data.
It does not go well for the tools, middleware.
Use different indicators and words for the layers:
- business logic - data.
- tools middleware
Having well defined set of names associatied with their types and meaning (metadata) is making a technical realization easy.
It would be even far better having a generic standard approach for that.
It is something I have never seen an attempt within the ICT. Document systems: archiving, connecting to busienss workflows are existing.
Why don´t they exist in the software development workflow?
Starting a local attempt:
Naming standard like ibrarians have a succesfull approach. Includes the Intial end End of life stages with versioning
As those namings conventions aren´t generic, porting the solution to another environment is almost impossible.
Changing a technology can be a business requirement.
The implementations can be continued without a generic nameing convention using an in house local one that based on tools that are convenient available.
Naming conentions are both for a technical solution and for the daily human communciation important. When the same word is used for "completion of work" an for "destroying the work" the problem starts with finish.
Managing people isn´t my priority. Getting aligned to practice at organizations to get things done are the daily way of life.
The daily stand-up
Knowing what the colleagues are doing is important with a shared business goal.
The implementation of a stand-up can be brought in mandatory. I would assume sitting in each neighbourhood and doing that during working on items, would be sufficiënt.
From the common ground in a technical approach there is something strange going on:
- Forced is using hyped modern technologies although there are bleeding edges not solved well.
- The bleeding edges are not marked to solve and avoided for the time being but are a trigger to get in more modern technology with bleeding edges.
- Asked is a the keep it as simple and cheap as possible, lean agile.
The diagonal connections at both ends in the sitemap are defined instead of the normal vertical siloed lines.
The surprise is: they are practical in understanding the misunderstandings and big distances at organisations with processes.
Epilogue - Operational
Building and / or doing the operational work.
Making your mind up how to present all information was the first step.
Starting and finding yourself in trouble by the work to be done and still not knowing what is to do for better, time passes.
Epilogue - Tactical
The usual discussions are daily management involvement.
There is an elephant, the big boss likes to be bothering with technical details when he is having a problem.
The simple solutions are " build a database" - " roll out an app "
Ending a journey.
I used this picture at the end of chapters, intention: following a logical sequential order.
This picture is personal (holidays). An entrance and exit of Monemvasia, laconia Greece.
Being both, the single pathway (the name in greek) it is unclear whether it is the start or an ending.
As long as I am updating chapters somewhere, there is no end.
👓 Restart at high conceptual level
Missing links - related to the 7W´s
Unhappy on what is going on.
Sometimes you get a feeling there is some path still to go, you are not at the real destination yet.
Not really aware what it is until gettting some hints and a little bit being hurt.
The explanations are in the many detailed documented design topics. There are ideas in those not common mainstream, rather disruptive.
Summarize - Explanations
Only a summarize what is bothering me is given here under 7w´s.
An illustration can say much more than a lot of words. I included many illustrations.
Inverted pyramid idea Robert Greanleaf.
My elucidation for my personal figures when needed, on request.
Expectations Project management.
At complicated situations everybody can be right, form his viewpoint. Viewpoints being that different they can´t be true both.
Other words, hypes, working approaches: Scrum, Agile, Lean six sigma, Kanban
Mythical man month
Brooks observations are based on his experiences at IBM while managing the development of OS/360.
He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further.
He also made the mistake of asserting that one project -involved in writing an ALGOL compiler- would require six months, regardless of the number of workers involved (it required longer). (wikipedia)
The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it".
The book is widely regarded as a classic on the human elements of software engineering.
Critism Project management.
What the frustrations are, the best is by infographics.
The Dead Horse Theory
- Buying a stronger whip.
- Changing riders.
- Threatening the horse with termination.
- Appointing a committee to study the horse.
- Arranging to visit other countries to see how others ride dead horses.
- Lowering the standars so that dead horses can be included.
- Re-classifying the dead horse as "living impaired".
- Hiring outside contractors to ride the dead horse.
- Harnessing several dead horses together to increase speed.
- Providing additional funding and/or training to increase the dead horse´s performance.
- Doing a productivity study to see of lighter riders would improve the dead horse´s performance.
- Declaring that as the dead horse does not have to be fed, it is less costly, carries lower overhead , and therefore contributes substantially more to the bottom line of the economy than doe some other horses.
- Rewwriting the expected performance requirements for all horses.
- Promoting the dead horse to a superviory position of hiring another horse.
Another famous one.
- A clear overkill by managers micromanagement.
- Blaming the worker not fullfilling unrealistic expectations.
- Rewarding managers for the excellent peformance.
Of course there are a lot more than those. What is not mentioned in these two infographics is:
- Lack of coöperation by not shared business goals (silo´s).
- Not willng to change with correct effective working innovations.
ICT project management.
The change in managing ICT is a fast continously change.
The Design Thinking process first defines the problem and then implements the solutions, always with the needs of the user demographic at the core of concept development.
This process focuses on needfinding, understanding, creating, thinking, and doing. At the core of this process is a bias towards action and creation: by creating and testing something, you can continue to learn and improve upon your initial ideas.
The design thinking process consists of these 5 steps:
- EMPATHIZE: Work to fully understand the experience of the user for whom you are designing. Do this through observation, interaction, and immersing yourself in their experiences.
- DEFINE: Process and synthesize the findings from your empathy work in order to form a user point of view that you will address with your design.
- IDEATE: Explore a wide variety of possible solutions through generating a large quantity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas.
- PROTOTYPE: Transform your ideas into a physical form so that you can experience and interact with them and, in the process, learn and develop more empathy.
- TEST: Try out high-resolution products and use observations and feedback to refine prototypes, learn more about the user, and refine your original point of view.
Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner.
The practices of AM should be used, ideally in whole, to enhance other, more complete software process such as eXtreme Programming (XP),
the Rational Unified Process (RUP), Disciplined Agile Delivery (DAD), and the Enterprise Unified Process (EUP) to name a few.
AXELOS is responsible for developing, enhancing and promoting a number of best practice frameworks and methodologies used globally by professionals working primarily in IT service management, project, programme and portfolio management and cyber resilience.
These methods, including ITIL, PRINCE2, MSP and our collection of cyber resilience best practice products, RESILIA, are adopted by private, public and voluntary sectors in more than 150 countries to improve employees skills, knowledge and competence in order to make both individuals and organizations work more effectively.
Cap Gemini SDM, or SDM2 (System Development Methodology) is a software development method developed by the software company PANDATA in the Netherlands in 1970. The method is a waterfall model divided in seven phases that have a clear start and end. Each phase delivers (sub)products, called milestones.
Agile or optimizing work.
Getting a feeling some things re are Sometimes you get a feeling having seen things before. Just different words being used. In this case Scaled Agile Framework
The Fate cartoon makes it clear.
Three layers strategy, tactics, operations are there.
The development stages like the waterfall approach.
This is like operating an assembly belt line, not the real innoviation or improvement. The reason: missing the business core process environment.
What the frustrations are, is best shown by infographics. The metroline of London is an option for getting lost.
A very old one showing the steps in a customer journey for delivery a toy, "swing tree".
Swing Tree project
The classic one. Seen already in the 80´s and never got outdated as legacy.
- How the customer explained it
- How the Project Leader understood it
- How the Analyst designed it
- How the programmer wrote it
- How the Business Consultant described it
- How the project was documented
- What operations installed
- How the customer was billed
- How it was supported
- What the customer really needed
New journeys to enjoy.
In the agile world, using the scrum syntax, the work is decribed as a "customer journey". They can be never ending stories.
At some time "no work" is the objective goal, going for a private journey, better described as holidays.
To be repeated predictable over and over again. Not really boring wiht this kind of feeling.
It is a holiday picture made at Lakka Paxos Greece. The transport and sleeping place being the place at home in the right corner with the colored fancy fish in the aft.
During the journey doing "sprints" by going from one place to another.
© 2012,2020 J.A.Karman