6 posts tagged with "Service Management"

Today, we are going to take a look at something a little different. We are going to talk about workload criticality, methods to assess how critical your workload is, and the ramifications of that criticality in terms of the Cloud.

PoC, PoT, Prototype, MVP, Pilot - what do they all mean? What is the difference between them, and when should you use them?

Today, we are going to take a look at a technical Cloud Product Development lifecycle - in my eyes, understanding these terminologies is key to determining:

• What kind of resources (i.e., both technological and human) do you need to dedicate to a product?
• Where should you align lifecycle management with your application or service?
• How likely is it that the the product makes a good market fit or solves an issue?
• Keep your product lean to avoid wasting the wrong resources at the wrong time
• Shift to a product-based mindset
• Focus on innovation and early feedback loops

And, of course - what to expect when people start using these words, often thrown together in a conversation and sometimes even put in writing in Statement of Works and Requests for Proposals.

Cloud Design patterns help build reliable, scalable, secure applications in the cloud.

Today, we will cover common patterns, their use cases, and considerations.

The patterns we will cover today are only a small set of common patterns documented in the Azure Architecture Center.

Troubleshooting Azure Open AI and API calls to OpenAI can be challenging, especially when you may not know where to start!

The idea of this article is to give you not only a place to start with some common scenarios you may run into but also a way of thinking - to help you troubleshoot. This is not a technical 'get-your-hands dirty, delve into those logs' type article.

I am a big fan of the KT, or Kepner-Tregoe problem analysis methodology, and I have used it in many scenarios throughout my career to help discover and test the root cause of various problems. So, we will use the base of this problem analysis methodology to help us troubleshoot the scenarios we will discuss in this article.

Being a 'Technical Lead' or 'Tech Lead' means different things to some people and organizations; based on definitions found online, a Technical Lead is:

"A technical lead is a professional who oversees a team of technical personnel at a software or technology company. They often lead software development or software engineering teams and troubleshoot technical issues that involve software development, engineering tasks and product releases."

Although I agree with this, I would flesh out a bit more around architectural governance (or technical assurance, which is what the problem this role or function is for) across it - it also doesn't need to be software development heavy; it can sit in the operational and delivery spaces as well (waterfall or agile) and is more than a specific role, but a frame of mind.

At a very high level, this is what a day in the life of a technical lead means to me:

Day in the Life of a Tech Lead​

• Work alongside: Technical Product Owners, Chapter Members, Architecture, Business stakeholders and Service Partners to develop/roadmap/architect and improve technology.
• Manage delivery and operational risks and dependencies, and remove impediments to the achievement of the team objectives
• Test and develop roadmaps for preview Cloud capabilities for immediate or future value
• Act as a Subject Matter Expert (or Consultant) to assist in Design Decisions, Monitoring, Cost and Capacity Requirements
• Develop Governance processes for onboarding services into BAU, enabling Technology Infrastructure and Operations staff to use technology in a consistent and secure manner
• Work alongside Security and Developers to enable cross-team visibility and collaboration
• Champion improvements in People/Processes and ways of working
• Work alongside Chapter Members and Chapter Lead to develop Training/Skill programs for Technical areas
• Develop and promote an 'everything as code', 'everything is automated' mindset
• Problem/Incident Management (i.e. Continous improvement)

A Technical lead mindset may look like below​

• Automate what's trivial, boring, mundane, and belittling
• Build what you can't buy. Buy what you can't live without
• Make your work visible. Shift your value to performance.
• Work is never completed. Establish feedback loops.
• Target high impact problems.
• Get out of the way of the work, think outside of the box, don't limit others.
• Try, Learn, Adapt, Try again
• Agile is about speed to adapt, not velocity
• Log what's useful, monitor what matters, alert on what's actionable
• Empower others while making sure that everything is auditable, standardised.
• We live in a VUCA (Volatile, Uncertain, Complexity, Ambiguity) world, you will never see perfect.

The views above are my own, but shout out to Teal Unicorn for independent consulting on Ways of Working, Continuous improvement; I attended a few of their workshops on Ways of Working, Ways of Managing and Ways of Consulting, and it helped me take a step back and look at what this kind of mindset may look like, or should be and current blockers.

Overall, I have noticed that Information Technology roles are now blending disciplines that once required specific job roles (ie Business Analyst, Service Delivery Manager, Developer, Architect), although pure technical roles still exist with Cloud technologies, different skillsets are required to get the most value out of technology stacks, as technology becomes more consumable. You may also be interesting in reading my thoughts on: The Cloud Frame of Mind

Hopefully this has helped or at least encouraged looking at problems differently, or areas of improvements for any readers out there!