CCIE or Null!

My journey to CCIE!

The TOGAF ADM – Part II

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

The TOGAF ADM – Part I

leave a comment »

In my last post we briefly looked at the TOGAF ADM. We won’t be able to fit it all into a single blog post but we will start to explore the ADM from a high level. ADM stands for Architecture Development Method and it organized in 10x different phases. These different phases are designed to assist organizations with keeping their business objectives & goals aligned the associated IT organization. IT departments have grown to be an important part of everyday business and even though we are in 2019 some companies still struggle with the relationship of aligning the business goals and their IT acronym jargon. The ADM works in a scalable phased approach allowing the left hand (the business) and the right hand (the IT department) to collaboratively work through meeting the desired objectives. Without further ado let’s jump in!

 

Preliminary Phase: The Preliminary Phase is an odd one, because it is outside of the phased ADM cycle however it is an important phase because this is when the architects get together and begin defining how the ADM will be interoperate within the company.

The following are outlined during the preliminary phase:

  • Architecture principles – Principles that align with the business and IT principles which will provide high level guidance on how the architecture team operate.
  • The scope of the enterprise – This how the architects determine how much of the enterprise they want to interact with and govern. The scope of the enterprise can also be broken apart by architecture partitions depending on the size and/or business goals of the Enterprise, or the different business units).
  • Creating the architecture team.
  • Identifying other processes that the TOGAF may need to interoperate with. (ITIL, change management, PMO, etc)
  • Governance methods.

Phase A: Architecture Vision: This is essentially the beginning of the architecture work and is kicked off by a Request for Architecture Work where a member of the enterprise wants to accomplish a goal and requires the architecture board to oversee the task. One of the big key points is to ensure the architecture work is sponsored by a high level member of the enterprise to ensure the architecture team has the authority and political backing to manage the project.

In Phase A, we our primary focus is to gather as much information as we can about the request. This where we ask the important questions:

  • What are the business goals.
  • Who are the stakeholders, what are their concerns or constraints, and creating a communication plan for keeping the stakeholders informed as the architecture work progresses throughout the ADM. Let’s also keep in mind the stakeholders might not be only on the business side, you will likely have stakeholders on the IT/IS side depending on the scope of the project.
  • Define the target architecture and identify risks that may concern the stakeholders during the journey of getting too that target architecture.
  • Develop / define the architecture vision and secure approval for the Request for Architecture Work document.

Phase B: Business Architecture: In Phase B, we continue to build off the information we gathered in Phase A. We continue our conversation with the stakeholders and determine each of their concerns. These concerns can be referred to as a view this ensures we know what each stakeholder is looking for allowing us to meet each of their requirements of the project. If the stakeholders do not feel their deliverables have been met they might not consider the project a successful.

We also need to consider what business processes are existing today (baselines) and what the target business architecture is. Once we know where we want to be, some type of gap analysis will be performed to identify what deliverables need to be implemented in order for today’s baselines architecture to meet tomorrow’s target architecture. Once we have gathered all the information we should have a complete business architecture document.


Phase C: Information Systems Architecture:  Phase C is really broken down into two separate domains, both of the domains follow a similar pattern and can be carried out simultaneously. TOGAF understands the importance of focusing in both the data & system/applications separately:

Data Architecture – Here we are talking about the data. TOGAF places emphasis and importance of the actual data, an important element that has not been brought up yet is the concept of building blocks and re-usability, if we can re-use this same data in another application or project that can minimize effort down the road making further project easier and potential cost loss. That is just one (or two) reasons why the data architecture is important.

Understanding that data architecture comes from knowing:

  • What data the stakeholders need.
  • What data do we have today (Baseline architecture), can any existing data models be re-used?
  • What data do we need to compile or collect to accomplish the desired architecture (target architecture).
  • This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture.

System/Applications Architecture – This sub-phase is conducted similar to the data architecture section, replace the the word data with application and add in any specific application or software flow diagrams.

  • What software/applications do we have today (Baseline architecture), can any existing applications models be re-used?
  • Define your application or functionality matrixes/diagrams. We are still very early in the ADM so most deliverables are still high level but having an understanding of what business process is linked to which application feature & what data each feature may need to interact with. We also may start considering user roles and permissions.
  • This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture.

Mindmap - Phase C

Phase D: Technology Systems Architecture: The is where we starting to consider the communications and compute requirements for accessing the data and applications. Since my experience is on the networking side of the world this is typically where I would really getting involved in some discussions. Hopefully though I would already be aware of this, as I should have been identified as a stakeholder in Phase A.

Phase D, follows a similar path as to what we did in Phase C, however it will be specific to the system/network concept.

  • Are their existing technologies standards or implementations that can be used.
  • Understand your baselines and target architectures.
  • This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture
  • Gather the requirements from the stakeholders, some key points you want to understand are the desired performance, availability requirements, latency, etc.
  • What kind of diagrams or models will need to understand and convey the architecture deliverables.

Mindmap - Phase D

From a quick high level, Phase B, C, & D following a similar routine however they each focus are their specific knowledge domains. Now, to keep this post from running away, I am going to be stopping here. The ADM is a powerful and detailed methodology, my goal here was to give a simple overview, we will continue exploring the TOGAF ADM in my next blog post.

Random Note: I created all the images in this post using a mind mapping application for note taking during my TOGAF studies. Sometimes mind maps can get a little out of control but I hope this format worked out well for presenting the ADM and the high level steps of each phase.

Written by Stephen J. Occhiogrosso

August 10, 2019 at 8:09 AM

TOGAF 9 Certified

leave a comment »

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

Wireshark 3.0 Released

leave a comment »

Wireshark

Recently, Wireshark dropped a major release which adds a few cool features (some new and some old). However outside of the new features, there is one major under the hood change this feature introduces. WireShark v3 for Windows now ships with Npcap as opposed to Winpcap that we have been used forever now. Npcap is actually part of the NMAP project which while Npcap is build of Winpcap Npcap gets a little more love in regards to up updates and being actively worked on. A while back I did a look at how Winpcap interacts with the NIC cards and captures packets, Even though Npcap is based off Winpcap I am curious to see if that underlying interaction has changed (more to come on that, or I’ll just update this blog post later on with my findings)

A few other features:

  • IP Mapping has returned
  • Monitor mode support for Windows wireless analysis. This is a huge one in my book, this functionality was brought over from the Npcap change.
  • A few other random tidbit, bootp dissector is getting renamed to dhcp. Similar to SSL getting renamed to TLS.
  • ciscodump now supports a proxy connection, I am going to need to check this out, as ciscodump utilizes the Cisco EPC capability. Which apparently I haven’t got to kick the tires on just yet. So, I think I am late to the game on this one, but proxy supports make this easier for some environments.
  • There are quite a bit more changes, many new protocols were added and well as even protocols were updated.

For the sake of brevity I don’t to cover everything, just a few of the pieces are find more interesting and useful.

Link to the Wireshark release notes page.

Written by Stephen J. Occhiogrosso

March 4, 2019 at 11:00 AM

The -B Domain for Cisco Access Points

leave a comment »

I know I am a few months late on this one, but figured it would be worth throwing out there. Earlier in the year Cisco updated and released its access points to be compliant with -B domain regulations set forth by the FCC in North America. After May 1st 2016, all Access points ordered and shipped will compliant with the -B domain, meaning you will not be receiving any access points that are part of the -A domain. This might not seem like a big deal however depending on what version of code you are running on your controller, you might find yourself wondering why your new -B domain compliant access point is not joining your wireless controller.

Depending on which software Rev you are running, you may or may not meet the minimum software requirements. This will require you to upgrade the code on your controller before you can actually use these new -B compliant access in your network.

  • IOS-XE 3.6.XE
  • 8.3.102
  • Post v8.2 MR3

The -B domain conveys the following changes:

  • UNII-1 is allowed for outdoor use. Originally this part of the 5Ghz band was only regulated to indoor use.
    • Something to keep in mind when the CWNP updates its exam syllabus.
  • UNII-1 is now allowed to transmit power of 1W for both indoor and outdoor use.
    • However restrictions have been put on the EIRP when used outdoor with a 30 degree horizon.
  • New Spectrum density for the UNII-3 bands.
  • Re-opening on Channels 120, 124, & 128 with the restrictions of new testing requirements.
    • This is where things get interesting, as the access are supposed to watch out for other TWDR (Terminal Weather Doppler Radar) signals to avoid interference. So we will see how this goes. However this could provide us some much needed spectrum space in the 5GHz band with 802.11ac creating wider channels.
    • Remember to make sure you clients will operate on these channels before enabling them.
Sample ordering info for the new -B domain compliant access points.

Sample ordering info for the new -B domain compliant access points.

Written by Stephen J. Occhiogrosso

November 19, 2016 at 9:00 AM

Posted in Uncategorized

SourceFire & AMP showing up on CCNP: Security

with one comment

sourcefirelogo

Looks like the SITCS Exam, that is part of the CCNP: Security exam is going from v1.0 to v1.5. SITCS is the exam oriented around ‘Implementing Cisco Threat Control Soluation’. Now, it only makes sense as the original version of this exam was more geared towards Cisco IPS & CX which has since been EoX’ed some time ago. If you have been studying for your CCNP: Security and are getting ready for SITCS v1.0 exam you still have time, Cisco kept the original exam available till December 31st of 2016 so you have until the end of year.

Cisco has published a dedicated PDF regarding the charges between the exams, which can be found here.

In a nutshell though:

  • EoX – Cisco IPS and CX software have been removed.
  • SourceFire & AMP Software has been added in as the replacement topics.
  • The exam code will be changed to 300-210 from 300-207

In my opinion, SourceFire documentation is still a little scarce even nowadays (Finding the proper version of User Agent on Cisco.com is still a bit of scavenger hunt) but hopefully this push for SourceFire knowledge will change that! (In the meantime I highly recommend checking out CiscLive365 and going through the available sessions, small collection here but it has not updated since Cisco Live 2016.)

As always, happy hunti…I mean studying!

Written by Stephen J. Occhiogrosso

September 22, 2016 at 9:00 AM

Wireshark Tid-bit: De-crypt SNMPv3 in Wireshark

with one comment

I recently found myself troubleshooting some SNMP connectivity between a particular set of devices and an NMS. Connectivity did not appear to be the problem as IP Connectivity was there and MIB walks were successful, however some interesting errors were still getting reported on the NMS. As I captured the packets to verify this connectivity, I said to myself ‘If only I can see what the NMS was asking for specifically and what device in question was replying back with’. This led me to check out the SNMP protocol settings in Wireshark, I mean Wireshark can de-crypt HTTPS traffic (with the private key) and wireless WPA traffic surely it can de-crypt SNMPv3. Behold it was true!! I was able to de-crypt SNMPv3 packets, and see what was really going on.

To add SNMPv3 information into Wireshark:

Access your Wireshark preferences: Edit -> Preferences -> Protocols -> SNMP

Wireshark SNMP Settings

Where you see ‘Users table’ choose edit:

WireShark SNMP User

From here we can enter the SNMPv3 settings we need:

  • Engine ID
  • SNMP USer
  • Authentication & Password – MD5 or SHA1
  • Privacy & Password- DES, AES-128, AES-192, or AES-256

Once you enter the correct information and choose ‘ok‘ Wireshark will automatically de-crypt any relevant packets.

I feel like this is something I should have known about for a while now, but I supposed I don’t find myself troubleshooting SNMP connectivity too often. Figured I would get the word out there!

Written by Stephen J. Occhiogrosso

February 19, 2016 at 9:00 AM

%d bloggers like this: