Friday, September 21, 2018

What Is The Most Important Part of Architecture?


I always find it interesting to hear what people view architecture as. A lot of people think it’s just about the design aspect, where you get to put pen to paper and create a solution. Even more people think that it’s just about putting together different technical components in a server room. And these people have interesting opinions on the importance of those activities to architecture. But, at the end of the day, the MOST important part of architecture is one thing and one thing only: requirements.
Requirements
Without requirements, you have no idea if you are actually designing a solution that matters. Without requirements, you have no way of knowing if those technical components that you are including on the server rack will actually be used. In short, you are only spending money without knowing if it’s worthwhile.
We all know of solutions that have been put into place and yet no one uses them. Why is that? Well, one very simple reason – no one bothered to check with the stakeholders what exactly they wanted. What’s the point of spending money on all those components if no one is going to use what you put together? That’s why you gather requirements so that you don’t waste money and actually have a usable solution. Not a solution that works but one that is actually used.
When you gather requirements, you don’t just sit down at a desk and dream up what you think the solution should meet. That’s just navel gazing and it’s no better than designing or building without requirements. Requirement gathering is all about talking to stakeholders to understand what they want and need. You gather those requirements and only then do you start looking for a design approach.
Now, when you say stakeholders, what do you mean? Well, remember that stakeholders include everyone that has a stake in how a solution works. So, it’s not just the end users that are interfacing with the solution or just the business owner who is providing the money. It’s also the operations folks that are supporting the solution. Remember, if the operations team can’t properly support a solution or would need to spend extra money to support it, then you have a more expensive solution than you may have wanted in the first place. So make sure you talk to the operations people about what they need in a solution as well.
Now, you’ve identified the stakeholders that you want to talk to and you are now scheduling meetings to gather those requirements. How do you do that? I would highly recommend that you don’t talk to them all in one room at the same time. There is always the proverbial ‘wallflower’ that sits in the back and doesn’t say anything but who will have a very valid point about a requirement. You will have domineering personalities that will want to be the focus of the meeting. And there will be people that lose focus during the meeting and do other things.
Instead, schedule one-on-one sessions with every stakeholder. A good requirement gathering session will average to 45 minutes per person, so schedule an hour for each person. Trust me; it may seem like you are spending a lot of time on this but it will save you a lot of money over the longer term if you do things correctly from the start.
Now, you’ve scheduled your session with your stakeholders. How do you conduct the meeting? Well, first off, treat it like you would an audit. You don’t go in with preconceived ideas of what the solution is. What you do is ask your stakeholder very broad, open-ended questions and let them talk. Don’t show any indication on how you feel about a particular requirement that they bring up, just note it down. I would highly recommend that you have a spreadsheet for all the different requirements areas (for example, availability, security, maintenance, usability, etc.) so that you don’t forget to ask about them. And then just let the stakeholder talk and go in whatever direction they want to go in.
Once you’ve interviewed all the stakeholders, consolidate all the requirements and replay them back to the stakeholders as a whole. This is the time that you’ll want to have all the stakeholders in one room. You want them to see what the requirements are and agree to them before moving on. And you are bound to have conflicting requirements that will need to be hashed out between the stakeholders and reach mutual agreement.
Once the stakeholders have agreed to the requirements, you can now start going down the road of designing and building your solution. But ALWAYS refer back to the requirements at every phase. Don’t just gather the requirements and forget about them. Those requirements drive the success of the project, and the closer your end solution is to those requirements the more successful and used the project will be.
Oh, one more thing. There are always requirements that come up AFTER the gathering phase. If that happens, two things have to be kept in mind. First, it means that you didn’t do a good job at collecting the requirements in the first place and you need to figure out a way of improving your requirement gathering process. Second, accepting new requirements at this stage means going back and changing designs or builds, which costs time and money. Often, it’s better to just leave the new requirement for the next phase of the project rather than going back and reworking your design.
Requirements are the flesh and blood of a good solution, regardless of whether you are talking about security, infrastructure, application, or a network solution. And if you do it properly, your requirements can help make you a very successful architect moving forward.

If you found this article interesting and want to learn more about architecture and cybersecurity, you can explore Hands-On Cybersecurity for Architects. The book follows a clear, concise, and straightforward approach to explain the underlying concepts and enable you to develop, manage and securely architect solutions for your infrastructure.  
( This sponsored post is part of a series designed to highlight recently published Packt books about leading technologies and software applications. The opinions expressed are solely those of the author and do not represent the views of GovCloud Network, GovCloud Network Partners.)




Cloud Musings
( Thank you. If you enjoyed this article, get free updates by email or RSS - © Copyright Kevin L. Jackson 2016-2018)



Sunday, September 16, 2018

Cloud migration best practice Part 4: Executing the migration


This series has stepped through cloud migration best practices. After providing an overview, we discussed:
With all of that completed, it’s now time to select the right cloud service provider (CSP) and finally execute the migration. Cloud provider selection is an area that many enterprises ignore. Executives looking to take advantage of the real business value that the cloud delivers often view providers simply as commodity technology providers. With this mindset, decision-makers usually pick the most familiar name. But this strategy is little more than throwing the dice.

A Smarter Way to Select a Provider

Cloud service provider selection requires a well-developed hybrid IT strategy, an unbiased application portfolio review and the appropriate due diligence in the evaluation of all credible cloud service providers. When discussing this linkage, I leverage the Digital Transformation Layered Triangle as a visualization tool. After agreeing to an appropriate high-level hybrid IT strategy, a digital transformation core tenant, candidate CSPs capabilities must be compared based on their:
  • Availability of technology services that align with the business/mission model.
  • Availability of data security controls that address legal, regulatory and data sovereignty limitations.
  • Compatibility of CSP sales process with enterprise acquisition process.
  • Cost forecast alignment with budgetary expectations.

Understanding Cloud Service Agreements

Comparing cloud service agreements from the remaining viable service providers is next. These agreements typically have three components:
  • Customer Agreement: Describes the overall relationship between the customer and provider. Service management includes the processes and procedures used by the cloud provider. Thus, it’s crucial to provide definitions of the roles, responsibilities and execution of the processes. The customer agreement does this. This document can be called a “master agreement,” “terms of service” or simply “agreement.”
  • Acceptable Use Policy (AUP): Defines activities that the provider considers to be improper or outright illegal. There is considerable consistency across cloud providers in these documents. While specific details may vary, the scope and effect of these policies remain the same, and these provisions typically generate the least concerns or resistance.
  • Service-Level Agreement (SLA): Describes levels of service by in terms of availability, serviceability or performance. The SLA specifies thresholds and financial penalties associated with violations of these thresholds. Well-designed SLAs can avoid conflict and facilitate the resolution of an issue before it escalates into a dispute.

Designing a CSA Evaluation

The CSA Evaluation must take into account all critical functional and nonfunctional organizational requirements and IT governance policies, to ensure:
  • Mutual understanding of roles and responsibilities.
  • Compatibility with all enterprise business level policies.
  • An identifiable metrics for all critical performance objectives.
  • Agreement on a plan for meeting all data security and privacy requirements.
  • Identified service management points of contact for each critical technology services.
  • Agreement on service failure management process.
  • Agreement on disaster recovery plan process.
  • An approved hybrid IT governance process.
  • Agreement on a CSP exit process.
This due diligence process maximizes the success probability of any cloud migration program. With CSP selection complete, the organization can now tackle the hard work of executing the actual migration. This task should include:
  • Planning and executing an organizational change management plan.
  • Verifying and clarifying all key stakeholder roles.
  • Detailed project planning and execution.
  • Establishing internal processes for monitoring and periodically reporting the status of all key performance indicators.
  • Establishing an internal cloud migration status feedback and response process.
The most important lesson learned across all industries is that cloud migration is not a project for the IT team alone. This is an enterprise-wide endeavor that requires executive leadership and focused change management efforts across multiple internal domains.


This post was brought to you by IBM Global Technology Services. For more content like this, visit ITBizAdvisor.



Cloud Musings
( Thank you. If you enjoyed this article, get free updates by email or RSS - © Copyright Kevin L. Jackson 2016-2018)



Cloud Migration Best Practice Part 3: Application Portfolio Analysis


In part three of this series on cloud migration best practice, I will focus on migrating the application itself. If you haven’t had the opportunity to read our recommendations from part two, “Classifying Your Data,” check it out — those activities are crucial to the decisions addressed in this installment.
While many organizations are aggressively moving applications to the cloud, they often set the criteria for a cloud service provider (CSP) without the necessary technical and operational due diligence. This widely observed error typically leads to migration delays, failures to attain expected business goals and general disillusionment with cloud computing. However, avoiding this disappointing experience is relatively easy. All it takes is executing an application portfolio screening process that takes a look at:
  • The most appropriate CSP target deployment environment.
  • Each application’s specific business benefits, key performance metrics and target return on investment.
  • Each application’s readiness for cloud migration.

Build a foundation

The first step in the screening process is determining the most appropriate cloud deployment environment. This practice establishes an operational foundation for subsequent service provider selections by using relevant stakeholder goals and organizational constraints to guide service model, deployment model and implementation option strategy decisions. Enterprises transforming their information technology should evaluate all available options by analyzing an app transition across three specific high-level domains and sub-domains, such as:
  • IT implementation model
    • Traditional
    • Managed service provider
    • Cloud service provider
  • Technology service model
    • Infrastructure-as-a-Service
    • Platform-as-a-Service
    • Software-as-a-Service
  • IT infrastructure deployment model
    • Private
    • Hybrid
    • Community
    • Public

Cloud computing domains

These domains and sub-domains outline a structured decision process for placing the right application workload into the most appropriate IT environment. This is not a static decision: As business goals, technology options and economic models changes, the relative value of these combinations to your organization may change as well. Plus, single-point solutions are rarely sufficient to meet all enterprise needs. By the end of the cloud migration journey, an organization may require a mix of two, three or as many as 10 variations. Infrastructure variation is why an organizational hybrid IT adoption strategy is crucial. Figure 1 is an example application decision matrix suitable for this step.


With target deployment environments selected, companies should evaluate each candidate application regarding their business benefits and ability to leverage cloud computing’s technical and operational advantages. Using a simple qualitative scale, stakeholders should agree on:
  • Key performance indicators relevant to business or mission owner goals.
  • Expected or target financial return on investment.
  • Each application’s ability to use cloud infrastructure scalability to:
    • Optimize time to deliver products or services.
    • Reduce time from business decision to execution.
    • Optimize cost associated with IT resource capacity.
    • Increase speed of cost reduction.
  • Possible application performance improvements that may include:
    • More predictable deployment and operational costs.
    • Improved resource utilization.
    • Quantifiable service level metrics.
  • Value delivered by improved user availability that may be indicated by:
    • Improved customer experience.
    • Implementation of intelligent automation.
    • Improved revenue margin.
    • Enhanced market disruption.
  • Enhancing application reliability by:
    • Establishing enforceable service level agreements.
    • Increasing revenue efficiencies.
    • Optimizing profit margin.

Determine KPIs

Figure 2 provides a baseline KPI and ROI model that can be easily modified to effectively manage a qualitative assessment across time, cost, quality and revenue margin criteria.


The final step of this application screening process is determining each application’s readiness to actually migrate to the cloud. This step should qualitatively assess the alignment of an application’s cloud migration decision to the organization’s:
  • Risk appetite and risk mitigation options.
  • Ability to implement, manage and monitor data security controls.
  • Expected migration timelines.
  • Expected ROI realization timelines.
  • Current culture and necessary organizational change management resources.
Performing an application portfolio screening process can be useful in aligning cloud application migration projects with organizational business, technical, security and operational goals. It can also avoid application migration delays, failed business goals and team disillusionment by building and monitoring stakeholder consensus.
In the next and final installment of this series, data classification and application screening are linked to cloud service providerselection and application migration execution.


This post was brought to you by IBM Global Technology Services. For more content like this, visit ITBizAdvisor.



Cloud Musings
( Thank you. If you enjoyed this article, get free updates by email or RSS - © Copyright Kevin L. Jackson 2016-2018)