When one thinks of demand planning it is hardly ever consider to be part of the IT realm. It is related more to a supply chain management process. Where levels of inventory are increased or decreased based on the demands of the customer, and profits increase or decrease for a given product. Effective demand planning for supply chains will help a corporation predict these peaks and valleys. Now a days Enterprise Architects have to look at IT demand planning not from a product level increase or decrease but from a perspective of does the business demand and strategy meet the IT capabilities and service portfolio. I have said this before in my other blogs the IT budgets are shrinking and business are expecting more. IT Demand Planning is becoming more of a priority for Enterprise Architects to implement, and improve the quality of implementation for the business. IT is having difficulties understand what project they currently need to complete let alone what the future state vision will be. Another metric that is not being focused on is resource utilization. When it comes right down to it is IT failing at demand management, and in these other aspect related to demand management, IT also is delivering products and services that the Business Units and Stakeholder do not need or even want. Leaving the business open to look elsewhere for products and services.
Looking into it more closely, IT is more concerned with what is delivered to the business units and stakeholders rather than what is important for the business to succeed. For example IT’s concerns are Devops, Databases, and networks) just to name a few. IT rarely prioritizes demand based on business strategies and priorities, and most importantly not doing project based on what will help the business. A lot of times I will see IT and project management put together a project that is on time, within budget, but does not really meet the needs of the stakeholders and business. This all goes back to poor demand management and a conventional way of thinking for IT. Just throw new equipment at and we are good to go. This does not benefit the business. Yes it may be under budget, within the time line, and functioning but does it really fit the Business “TRUE” needs.
EA needs to implement a demand request process that incorporates governance. In which projects go through governance and are approved with business representation, and not something thrown together with limited thought of does this solution really fit the business need, or the old adage the squeaky wheel gets the grease, so that business unit takes priority if they complain enough. Enterprise Architecture, governance and the business representation will have to throw out the old way and be able to merge both sides demand and supply if they ever plans to be successful implementing demand planning.
My company has a demand request process where a demand request comes in from the business unit or stakeholder. A deeper understanding of the request is then obtained by the business analyst from the business unit/stakeholder who made the request. This is then presented to Enterprise Architecture Review Board (EARB) to determine if it is project or operations. From there it is either given to Project Management or the Service Managers to take ownership of the project. Once it is at this level there are think, plan, execute iterative. A think iterative is where the team gets together and decides is this the right solution for the business objective or can something else better be done for a solution. Once this iteration is completed. It goes to governance for approval. The next iteration is actually planning out the task. Then back to governance for one final blessing. Then execution iteration, which is executing the tasks developed in the planning phase and implementation. Through this whole process all stakeholders are kept informed (or included if need be) either by the BA, PM, or Service Manager. Once completed it is then handed over to the business and add to the service portfolio. This processes only down fall is it does not include future state and gap analysis, and cost, but in its defense it is a new process, so it has a long way to go until full maturity. It is a good foundation for demand planning, and in hopes that someday it will be the corner stone for all demand process at the organization.
https://dzone.com/articles/capital-one-a-devops-powerhouse
IT strategies are an encompassing plans that Enterprise Architects use to support the business strategy. The IT strategies should include finance, infrastructure requirements (Hardware and Software), security management, communication management and risk management. To have good IT plans requires good leadership, so to put the IT plans in alignment with the business strategies and to insure the organization success. Capital One’s corporate leaders have taken DevOps “beyond just process.” For example, the challenge of “building a server in their datacenter” led to “next-gen infrastructure using a public cloud and internal cloud, while they also developed their own open source tool, a DevOps dashboard called Hygieia intended to track the progress and health of their pipeline” Leadership does not just come from executive that drive the strategies. It allows for execution of IT strategies giving and opportunities for leadership skills to be developed from the ground floor up. Giving a better way to empower employees to reach out to the business and be focused on the business strategies. This type of leadership helps organization from top to the bottom create buy-in for both the IT strategies and enterprise architecture (EA). IT strategy come in many different shapes and forms such as IT is the business, IT supports the business, or IT acts likes a business. Capital One IT strategies for DevOps is IT is the business. They have transformed from being an IT organization that acts like a business to an IT Organization that leads the business. In organization such as Capital One, who have current strategies which allows IT to function within the lines of business (LOB), and be more aligned with the business strategy, which is providing more chances for success. Capital One DevOps needs to be careful not to become an ‘Ivory Tower’ and continue to concentrate on being customer focused and keep sharing with the development communities .
Capital Ones DevOps always strives for IT excellence in delivering DevOps and open source infrastructures to its stakeholders and business units. Their business and IT strategies are centered on Technology. Capital Ones, allows their biggest products, which are software and big data to play a central role in leading the digital revolution. IT strategies such as these, allows Capital One to turn the old ideas of credit cards to a fully digitalized banking system. This gives their customers choices of mobile usage, Web Client, with digital banking designed for the customer. They are able to do this through software built from DevOps wrapped around data capabilities. Capital One has heavy driven core IT strategy built around data technology and data best practices, and utilizing DevOps model to automat and consolidate the build process. This provides a payoff of, DevOpsSec which allows for reconstruction of Capital One’s development, business, operations, and information security for stakeholders into optimal alignment within a code-based pipelines. This builds customer’s expectations for products such as mobile, better online products, ATM, and yes even wearables. Capital one is now able to build an IT service portfolio catering to these customer’s needs and IT strategies that center on holistic processes for the technology domains.
Capital One now has IT strategy that identify common process and technology. The creation of a common infrastructure and shared business components, lowers costs, reduces the risk of redundant functionality, and increases flexibility. Capital Ones uses IT effectively because it is considered during the business strategy and planning process. Including IT early allows for the business initiatives to allocate the right IT capabilities. In doing so the systems will not be implemented until all solutions have been implemented, tested and signed off by the customer. A possible chance of failure can occur if the business strategy does not consider the advantages of IT early in the planning process. Making it seem like there is no need for IT. Which can cause the business not to be engaged in new innovative and cutting edge technology. This will increase risk and less-defined projects for the organization. This is not true for Capital One DevOps because they utilize policies that builds on open-source that is shared with stakeholders, internal business units and new vendor. This allows them to not only develop something cutting edge but give back to the developer community and be in the center of it. Which creates great test beds for new and current innovation.
https://www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/#5f4aa3f57860
The Iterative Approach is a powerful solution to address the complexity of finding the balance between the current and future state. The approach suggests finishing one iteration, rather than recursively doing a top-down design where each iteration of the top down design, basically makes one more level of details for the current state, which makes the future state a good possibility of not to be realized. The Iterative Approach allows the future state to advocate the breadth and level of detail of documentation applied to the current state documentation. These iterations should all be based on what the businesses requirements are.
First the future state is developed, and then Enterprise Architect Team (EAT) develops sufficient data on the current state to produce gap analysis that is needed for execution and implementation of the strategy. It is very easy to go down the rabbit hole with the current state, which is a wastes of resources and time to understand entire picture, so it is important for architect to stay on task. Once figured out the scope of documentation for the current state, it important to make sure the data is correct. If the data is not correct this can cause problems with data integrity, stake holders and executive might have different data or incorrect to boot. Ways to solve this is through automation or data warehouse, but these can cause problems with users pulling data a different time or downloading the data to their own servers and not keeping up with the source data. This is where data governance comes in. (That is for another blog.)
It is always a balancing act with the current state and knowing when the EAT has gone too far down the rabbit hole. If the plan is to document the data warehouse that is all that should be documented to establish gaps. Uneven levels of documentation may lead into Analysis-Paralysis for some organizations. EA is fundamentally a strategic approach, it may not make sense to document future state in too much of detail. Sometimes it makes sense develop future state and current state details just enough to satisfy stakeholder needs via correctly chosen viewpoints. The threads between future state and current can be easily broken that is why it is important to incorporate an understanding of applications, infrastructures and databases viewpoints.
Using the Iterative Approach for current state architecture focuses the efforts on high value strategies guided by the future state. This practical approach avoids wasting resources collecting unnecessary details of the current state and focuses on the requirement to accurately develop an architecture plan that will plan for the future. There should be an expectation by customer on a future state architecture and the areas of recommendations Enterprise Architecture Team expect to address. Keep in mind that Enterprise Architecture Team can always iterate and refine Enterprise Architecture, architecture artifacts, maturity assessment reports, and principles as you learn through executing the Iterative Approach.