[image credit: kalhh on pixabay.com] |
An Ode to the IT industry, and organizations everywhere.
[image credit: kalhh on pixabay.com] |
An Ode to the IT industry, and organizations everywhere.
[image credit: Alexas_Fotos on pixabay.com] |
[image credit: pixabay.com] |
Today's meditation: Strategic Initiative Planning
If you asked me to help your organization launch a strategic initiative, there are important steps that I would recommend - and the order is critical:
(ordered with intent...phased, incremental, and iterative are implicit - while Big Bang - or Big Design Up Front - is most certainly not)
1. WHY:
Our initial discussions are going to focus on getting crystal clear on why you think this strategic initiative is important, what problems do you think it will solve - or what opportunities do you think it will create.
What are the market forces driving this initiative idea?
What are the possible 2nd and 3rd order consequences of chosing this particular strategic initiative (versus other possible alternatives) to your organization?
2. WHAT:
Everyone involved in this strategic initiative must be crystal clear on your priorities, objectives, desired outcomes, and goals.
What are the geographic areas in which this initiatve will be implemented?
What are the business requirements, and non-technical requirements?
What are the key metrics that will be critial - when measuring the success of this initiaitve?
What is the initial expected budget for this initiative?
3. HOW:
A clear understanding of the WHAT is vital, before we try to solve for the HOW.
What are the organizational artifacts (e.g., vision, roadmaps, policies, standards, specifications, constraints, etc.) - that will shape (or limit) the choices in developing an implementation approach?
How will this initiative be achieved?
What are the current set of business and technical capabilities?
What are the current businesses procsses - and what gaps may exists there, as well?
What resources are available, and what gaps may exist in the organizations skillsets.
4. WHEN:
When must this initiative be delivered/achieved?
Once we understand the potential gap between the organization's existing (and required) skillsets, or if the delivery date is so urgent that it won't allow sufficient time to upskill the organizatoin's personnel - then the WHO can be determined.
5. WHO:
Based on an understanding of the preceding, THEN we can begin assessing WHO is appropriate, and whether the work can/must be performed by personnel within the organizaiton - or whether exigent forces require engagement with one or more third-parties (vendors, partners, SMEs, contigent staff, etc.)
Far too often, I have observed ogranizations skip (or ignore) one or more of these steps - or seek to reorder the approach (e.g., selecting WHEN, before any other consideration is sufficiently examined, defined, understood). The outcomes then - easily predictable...
[image credit: aleksandra85foto on pixabay.com] |
This post is a placeholder for a collection of selected articles, suggested as background reading...(discovery-in-progress...)
https://jyx.jyu.fi/handle/123456789/93267
https://jyx.jyu.fi/bitstream/handle/123456789/93267/URN%253ANBN%253Afi%253Ajyu-202402061758.pdf
See: 4.1 Perceived EAM Value
"None
of the respondents completely agree with being satisfied with their
organization’s current EAM practices. About 70% disagree with the claim"
*** Pages 37-39
See: TABLE 8 Perceived EAM Value
Page-40:
"Overall,
of the synthesized constructs of EA Product Quality, EA Service
Quality, EA Culture/Attitude, EA Product Use, and EA Service Use,
presented in chapter 2.4.4, all were present in EAM value creation."
*** Important, Page-46
5.3 Limitations
"The
results do not come without limitations to validity. With 47
respondents, the sample size of the primary research was significantly
limited. The total methodology of the study was novel, with certain
exploratory features. Thus, the results are advised to be interpreted
as preliminary. The great majority of respondents worked in large
organizations with over a thousand employees, meaning this demographic
is best suited when interpreting the results. It may be that EAM value
is more likely to be achieved in the complex environment of a large
corporation. Additionally, all but one respondent worked in
organizations operating in Finland, meaning the results do not in their
large part represent the experiences of professionals working in
organizations not operating in Finland. Thus, it can be concluded the
results may not represent the complete population of EAM stakeholders."
***
"Another
notable limiting factor is difficulty in measuring EAM value due to its
typically indirect and/or intangible nature (Kluge, Dietzsch and
Rosemann, 2006; Tamm et al., 2011)."
I posted this answer, in response to a question posed by Sonya Natanzon, on LinkedIn
Noteworthy: Sam Holiday, PhD, offered a definition which focuses on the strictly monetary/cost aspects
I've created a poll on LinkedIn that may be of interest.
[source: Kelvin Meeks, LinkedIn poll] |
My proposed definition:
Technical Debt (noun):
1.
A consequence of the accrual of one or more intentional trade-off
decisions - or the unintentional absence/lapse of governance, oversight,
and maintenance.
2.
Technical Debt may arise from poor design choices, or exigent
decisions, that were contrained by available time, skill, or budget.
3.
Over time, Technical Debt may exhibit unexpected secondary aspects -
such as brittleness, cascading system failures, security
vulnerabilities, degraded performance, incompatibilities, failure to
meet regulatory and compliance requirements, etc.
4.
Technical Debt is usually a symptom of deeper underlying root causes.
When something is no longer supported, constitutes security vulnerabilities, or is no longer compliant - it becomes a type of technical debt.
6. Technical Debt, by my definition - is not a purely monetary consideration of ongoing costs - but encompasses a more holistic viewpoint of the consequences of failing to remediate some deficiency with respect to the technical aspects of design or implementation - that is a consequence of actions taken, or actions avoided.
Suggestions, discussion contributions, and other perspectives:
I thank the folks that have participated in the public LinkedIn discussion threads, or granted me permission to share these private exchanges, of their thoughts on the definition of Technical Debt:
Suggested Background Reading:
Standards:
Articles by others:
(articles in order of expected reading value)
Books on Amazon.com (in descending order of publication year)
Research Papers:
A few possibly useful tools/techiniques (as 2nd/3rd order proxies) for approximating some aspects of potential Technical Debt magnitude:
Cyclomatic Complexity Static Code Analysis, Software Measurement tools:
Dependency Analysis tools:
Lifecye Analysis: End-of-Life (EOL), End-of-Support (EOS)
2024-10-12 Sat
2024-10-29 Tue
[image credit: Pexels on pixabay.com] |
1. First, do no harm.
2. Don't leave a mess. Cleanup after yourself.
3. Listen, Look, Think, Act.
4. Be a good neighbor. Play nice.
5. Trust, but verify. Inspect what you expect.
6. Don't assume. Ask questions.
7. Help others.
8. Put things back in their proper place.
9. Rest before you get tired. Naps are good for you.
10. Don't rush, you might trip and fall
My weekend reading, doing a deep dive into the Rust source code for the rustls library, and its support for post-quantum (PQ) key exchange.
A modern TLS library in Rust
[image source: https://github.com/rustls/rustls/blob/main/rustls-post-quantum/src/lib.rs] |
|
rustls Security Advisories:
Additional resources:
https://badssl.com/
"badssl.com is meant for manual testing of security UI in web clients."
https://github.com/chromium/badssl.com
"Memorable site for testing clients against bad SSL configs."
Cloudflare Research: Post-Quantum Key Agreement
https://pq.cloudflareresearch.com/
https://tldr.fail/
"On essentially all domains served (1) through Cloudflare, including this one, we have enabled hybrid post-quantum key agreement."
Noteworthy Articles:
References:
NIST: