CCIE or Null!

My journey to CCIE!

Posts Tagged ‘Enterprise Architecture


leave a comment »

 Continuing right off from my last post, we going to continue our run-though of the ADM wrapping the last few phases.

Phase E: opportunities & Solution: Now, it’s time for us to review the outputs from our previous phases and to start defining the beginning of our implementation details. We do this in the form of creating the work packages, transition architectures, and architecture roadmaps. We have collected a lot of information in phases A through D on top of reviewing all this information we now need to start consolidating it.

Key steps in this phase are:

  • Review & consolidate the gap analysis from phases B-D
  • Review & consolidate the requirements across the business functions
  • Review & reconcile interoperability requirements & dependancies
  • Confirm readiness & risk for business transformation
  • Build you implementation & migration strategy, identify major work packages & transition architectures
  • Create architecture roadmap & implementation and migration plan.

Phase F: Migration Planning: During Phase E we started defining the actions that will need to occur for us reach the target architecture, during Phase F however we will finalize that the transition architectures and communicate with the stakeholders regarding how the solution will be delivered

  • We want to ensure that the stakeholders feel the implementation is a success, during this phase we will define CSFs (critical success factors). The CSF is a criteria that will tell us whether or not the stakeholders will consider the implementation successful.
  • While TOGAF and Enterprise Architecture is typically and add-on framework this is also where we want to ensure our implementation is coordinated with any other areas of the enterprise such as an existing change control board or polices.
  • Depending on the scope of the implementation we might have multiple work packages or implementations occurring to reach the target architecture, this is where we would re-visit our risk assessment and consider what risks may be relevant.
  • On that same note if we have multiple implementations we will also to prioritize those work packages, which implementation has the most business value or offers an acceptable amount of risk?
  • Determine if another iteration of the ADM needs to occur in order to accommodate one of the many work packages/implementations.
  • Finalize the implementation plan.

Phase G: Implementation Governance: This phase is rightly named as the architecture team won’t be performing any implementation tasks, the architects will be keeping an eye on the work to ensure that implementation plan set forth in Phase F is followed by the implementers. In Phase F we have set expectations with the stakeholders, we know the risks, timing, and the business values of the work packages being implemented now we need to ensure that becomes a reality.

  • Ensure the implementors understand the priorities
  • Setup architecture compliance reviews to ensure the implementation conforms with the implementation plan set forth in Phase F while also ensuring any risk associated with the work packages remain within any discussed or acceptable thresholds.
  • Review the implemented product and close the implementation from an architectural perspective.


Phase H: Architecture Change Management: Our solution has been implemented, delivered the business, and now it’s time sit back in our cozy chairs and relax right? Well, not really after a solution has been delivered and is being used by the business we need to ensure that the solution remains relevant and in sync with the business needs as the business requirements begin to change over time. As time progresses the business may need to add features or functionality to enhance the business value of solution this in turn would be requested via a ‘architecture change request’ it is then up to the architecture team to evaluate the nature of the proposed change. Then determine if this is a simple change that can be implemented via the typical enterprise’s change management process of if the requested change will require a re-design and the ADM cycle will need to be re-initiated in some fashion. In tandem with this the architects are also governing the changes to ensure the solution remains in line with business requirements and any IT, Enterprise, or architecture principles. Architecture change management can involve the following:

  • Deploy monitoring tools – This include monitoring the technologies as part of the solution or even the business value
  • Manage risks and the governance process
  • Develop change requirements to meet a target architecture
  • Analyze the change
  • Starting or activate the process of implementing the change


Phase: Requirements Management: Similar to the preliminary phase the requirements management phase is outside of the phased ADM cycle, but is just as important as any other phase if not more. The requirements management phase interacts with every other phase providing a way tracking and managing the inputs & outputs from every ADM phase. This information is tracked in the architecture repository.

That wraps up our run-through of the TOGAF ADM, while this was extremely high level I hope it offers a little insight to purpose and importance of each phase. There is much more to be said about the ADM and each individual phase, I could dedicate a post to each phase specifically but I wanted to start with a high level overview first.

Written by Stephen J. Occhiogrosso

September 2, 2019 at 7:49 AM

TOGAF 9 Certified

with 5 comments

After passing more technical certification tests than I care to count, the concept of studying for a non-technical exam seemed surreal. Studying for exam that was not going to teach or test me about protocols, signals, or configurations just sounded so foreign. I do have to admit that there were doubts, the thought of studying for exam that created paperwork and project delays took me just as much time to get over then the time I spent actually studying for this exam. Please don’t mis-interpret that comment I truly do understand the need for architecture and aligning IT with business goals (In my time in IT I have seen my fair share of projects that went off the rails, many of which could have easily been avoided by asking a few more simple questions or involving a few other parties) I just didn’t think I would be one to consider a certification like this. Trust me I love configuring in my CLI, designing on a whiteboard, digging through a packet capture to find that needle in the haystack, Splunking through network logs, and being that guy who knows how it talks and interacts. I suppose there is nothing wrong with stepping outside your comfort zone into new territory how else would we grow if we stayed within our own little bubble?

Studying for TOGAF 9.2 was fairly straightforward. I had used the following resources:

Studying the TOGAF 9.2 standard found on The Open Group website is enough to pass for the exam, but my study routine usually always involves a physical book and some CBT videos. I found the study guides to be very beneficial primarily due to the extra examples, the practice questions and exams which was key for me in building up my confidence level. I always find CBT videos helpful especially as background noise when I am doing something else around the house, in the case of TOGAF it was nice to hear someone explain the couple of concepts I initially had trouble grasping or visualizing. Plus the courses from Udemy were not very expensive when I had purchased them so for the cost I found them well worth it.

From the exam perspective, the TOGAF certification requires passing a part I and part II exam (which can be scheduled at the same time) at a Pearson Vue testing center. I took them separately at different times, this being my first non-technical certification I took a more cautious approach.

TOGAF certification steps from The Open Group website.

I always have concerns when it comes to frameworks (TOGAF, ITIL, etc) that introduce process and structure but I do see it as an unnecessary evil (as long as you don’t go overboard), especially in today’s world when we have the Internet of Things and different cloud environments radically expanding the capabilities of both IT and the business. The TOGAF framework does a good job at keeping both the business and IT operations in sync using the ADM as business goals are introduced and grow. Think of the ADM as almost like an extension of the project management process. (highly simplistic and incorrect description but hey)

So who is TOGAF for? Well, if you want to connect more with the business side of your company I recommend taking a hard look at TOGAF. This exam is definitely not on the technical side of the house but more so how you can further integrate the IS/IT projects with your business. As projects progress the ADM framework helps to ensure the work stays in-sync with what the business goals is/are. TOGAF ADM below:

TOGAF ADM, from The Open Group website.


However, I won’t be diving into the details about the ADM on this post. Maybe in a future post. Now, I am back off to the drawing board and see which certification is next of my chopping block. I do need to see how my Cisco certifications will transition to the new schema, if you have heard the certification from Cisco Live last June I recommend you give it a run through. Till next next my friends, happy studying!

Written by Stephen J. Occhiogrosso

July 19, 2019 at 4:17 AM

%d bloggers like this: