https://www.oreilly.com/ideas/5-tips-for-building-a-scalable-technology-stack

Reflections I

There are 5 important steps to consider when scaling out your enterprise technology stack.  The first and one of the most important in my opinion is to have a holistic view of the environment. When building out the stack we only look at what is being directly affected and not what might be affected downstream. (For example: a developer might have a faster way for importing data but can the back end handle the new sizable volume of data.) Having a holistic view of your infrastructure allows for less stress on a newly scalable stack. Step two and three I believe go together. Is the upgrade really necessary and make sure the new technology will cause problems with core functionality. Far too often Enterprise upgrade their technology just because they can, without considering the pain points such as training, staffing, and cost benefit. Maybe even third party vendor provides a better solution. Most important issues the new system may cause with integration causing the enterprise money that was not budgeted. It is too numerous for me to count that I have seen companies that I have work for or consulted with, throw caution to the wind and build technology stacks not knowing the risks, let alone if there was a better solution, or even if they needed the stack in the first place. The 4th step is to establish monitoring and feedback. It is very import that the stakeholders and executive see the success/failures, ROI and how the new technology effects human capital. The article refers to the 80/20 rule “do what you can at a lower cost because achieve perfection can be costly”.  Where I currently work this is the motto our infrastructure director lives by.  Another reason for monitoring it allows for trending on budgets and help to eliminate bad investing habits. As well as forecasting future state. This will Segway us into our final step Train, hire, and build a data-literate workforce. To reach the future-state and technology stack of the future. It’s time to build the workforce from within by open lines communication. Build both technology skills and something new to the IT workplace soft skills. Over all this allows all employees to contribute, and feel that they have a hand in the enterprises future state.

https://www.thoughtworks.com/insights/blog/implications-tech-stack-complexity-executives

Reflections II

Technology is changing so fast that an enterprise technology stack is no longer a single stack with a single vendor. It is now multiple layers of technology with multiple vendors. This is requiring executives and managers to be more informed within the technical realm, as the demands from stakeholders, business unit, and customer for digital environments backed up by big data increase, it is important for executive and manager to know the implications of the technology, so that they can make informed decisions in regards to stack technology.                                                 As these eco-systems begin to grow and become more reliant on teams with multiple skill sets and even reaching out cloud based computing services, built around DevOps to fill in the gaps. This type of IT environment is becoming more prevalent, and teams that are broken up into individual skill sets are a thing of the past. This type of eco-system is much more diverse which makes it harder to collaborate.  In turn it adds another layer of complexity to the eco-system such as business analysts and project managers to support the collaboration efforts. It is important for organizational leaders to have an understanding so that they can see the value added is not always about cost but filling gaps in the IT capability needs. Yes, it is costly to build out technology stack and staying ahead of the curve, but if the value out ways the cost that is what is more important if it puts the organization ahead of the competition.                                                                     I started with my organization five years ago. Our IT shop was pretty much siloed with a Windows Enterprise Application side and a Microsoft SQL back end database back end. Linux red hat websites with a file system back end. Also, a few legacy systems thrown in for good measure.  We had five system admins running the whole technology stack. Myself and four other guys, and we all had our own little niches within the stack. Today we have grown our technology stacks utilizing a plethora of different technologies and staffed with about 30 people and even reaching out to the cloud. We also used to be broken into different teams such as application, web, infrastructure and database. We are even building a project management office. Now it is making it easier for collaboration. The hardest part is the next step, building trust with the customer and breaking down the silos with other IT departments within the organization.

http://weblog.tetradian.com/2013/12/11/on-layers-in-ea/

Reflections III

The Enterprise Architecture layers of the stack are none for each of the frameworks. The author compares the layer of stack to a Penrose Triangle depending on which way you look at it will show a different point of view and we can be faked out on the real appearance.  He goes on to explain that if we only look at the one complete side such as with the Penrose Triangle then we are only working with a smaller subset not the holistic picture. For a true ‘architecture of the enterprise’, the valid approach is to assume that everything and nothing is ‘the centre’, all at the same time.”  In turn the author by making this point believes an architect that does not take this approach will have distorted and wrong assumption which will be doomed with failure.  There are only a couple things that I agree with in regards to this blog all the top is business and the bottom is infrastructure. I will even take it as far to say that I agree with the section “The view through the layers may be ‘non-reversible’, different from either side”.  I have seen where features were needed were left out of scope or better yet scope creep.  Why I think the author is wrong is because the layers in the stack have viewpoints, which will also define abstractions for models of the enterprise architecture, which help to focus on particular business context of the enterprise architecture. These context are determined by what the stakeholders want to be communicated and what should and should not be visible from a specific viewpoint. Hence it is completely focused on the stakeholder.  In order to use such viewpoint approach within an enterprise architecture, architects require a tool environment, which supports management of architectural views. The future state is also depended on these layers in the stack.  Where I work we have it broken down with these 4 layers in the stack.  Having the 4th layer allows for a framework with consistent and higher quality control of data. The productivity of information system will likely increase because of the application layer. The four layers will also provide a better systems analysis and design of the applications that link the business to the data, which will provide systems that are easier to use and learn.

5 thoughts on “Topic 1– Stack Overview

  1. Greg,

    I agree with your thoughts in reflection II. DevOps and Continuous Integration are technologies that must be enforced for organizations to increase their agility in delivering solutions. In my organization the development teams have pushed for these changes and done a lot of the initial implementations/research to put these systems in place. Our infrastructure areas haven’t gotten that “ah-ha” moment yet about how much automation can ease their everyday activities. I will probably be touching on this in a later blog, but i find a coding/scripting perspective is more rare in SysAdmins than it should be (at least in my experiences). Have you found this as well?

    • actually we have a mixture of system admins that actually use Jenkin and Puppet jobs for automation for our devops. This help our developers move code through the stack with Jenkins, Puppet helps monitor and setup up Lenux servers. With the group i work with now they are always finding different to solve problems. Before i got this job I would have agreed with you. We are a big Devops IT shop so i think that why we have more scripting talents

      • I have heard of Puppet before, i’ve been working with one of our sysadmins who is starting to use Chef (similar to Puppet) to automate our server deployments for a new server platform we are standing up. It looks your organization has right mindset for moving forward, which is great!

  2. I like your thoughts on multi-vendor IT stacks. I do agree that complexity often drives us to look at multiple vendors and multiple products. I do know from experience that the more we can keep the architecture unified and consolidated the better. That being said, when we use multiple vendors, we should make sure that they integrate and are part of a partner based ecosystem. All to often cost makes this decision and it can get ugly.

Leave a Reply to kdw1046 Cancel reply

Your email address will not be published. Required fields are marked *