IT Innovations

Following Innovation in IT can be a slippery slope.  There never is just one technology or one path to follow when it comes to IT or technology in general.  There is always a choice where one generally becomes the leader or the industry standard and the winner isn't always the best.  Look at the 80's first battle of video formats, VHS vs Beta.  Beta was technically superior yet VHS won out.  Same story when it came to HD-DVD vs BluRay.  Then you have some technologies that come out of no where and dominate the market and the landscape without a real competitor, Docker comes to mind immediately.

Investing in innovation can prove to be a disaster or a great triumph.

The REAL point is that IT will always be innovating and an EA must always move forward and evolve with it.  The speed and direction that the EA takes is again the tricky part.  Earlier adopters might catch a windfall or waste substantial amounts of time and money.  Enterprises that lag behind might loose customers and market share because they were too conservative and were not willing to leverage new (or newer) technologies and take advantage of things like greater efficiency or better service.  

Embracing innovation is great but must be done with care.  One can not sit around and wait to see who the winner is because they will be left behind by the time it's clear.  R&D is a cost center that provides no direct revenue but can pay dividends down the road in the matters of IT Innovation and technology selection. 

Lesson 06 - Emerging Business Architecture Layer

Emerging Business Architecture Layer

        As mentioned the Business Architecture Layer is the most immature of the layers of EA but is becoming more important and defined as time marches on.  As I have found out through my own experiences, being the instigator of change in an organization is very difficult, especially if you were an outsider like I was.  Part of the importance of the Business Architecture layer to EA is showing stakeholders and management how that change can help the business.  It helps define the future state, show gaps and redundancies and build a platform for all future IT projects.  It also can help as the business grows and moves with such like mergers and acquisitions and even divestitures.

Enterprise Solution Architecture

        This is where I "live" most of my working days and is one of the things that I enjoy most.  Except the documentation part, but it's a necessary evil.  It's really where the rubber meets the road so to speak.

Lesson 5 - Enterprise Security Architecture

I've said a lot on the topic of security in this little blog because I live it everyday through my job as a DoD Contractor.  Yet still there are security breaches that happen all the time.  I have 3 letters from OPM (Office of Personnel Management) about the probability of my information having been stolen during their well publicized breach.

The problem with Enterprise Security Architecture is that it is very difficult.  It crosses every other pillar in the entire enterprise.  Really, I think it should be the foundation.  Don't get me wrong, I don't like having to deal with security because it can be a real pain.  But it's necessary.  And it has to be done with constant vigilance because security changes even faster than the technology.

Currently my organization is going through the RMF (Risk Management Framework) process for one of our networks (we have several of varying classifications and purposes).  The process basically lays out our entire architecture and the security it has.  This security ranges from the machines to the physical cable installations.  It's that detailed.

What makes security a pain is that detail and the governance required.  Its all encompassing nature is why it's so complicated.  The only truly secure computer is one that is turned off.  Again, it goes beyond that.  For example in the DoD we have rules about cables.  Anything that is unclassified can be copper cable (normal CAT 5E or 6).  Anything ABOVE that can also be copper, but only if it's a secure space and even then it can not be in the same cable tray as unclassified.  The preferred option is that anything above normal unclassified (there are different levels of unclassified) be fiber optics.

I think back to years ago when we used to rotate tapes to an offsite location.  Those tapes were not encrypted.  Sure, they were carried by secure couriers but the media themselves were not.  That would never fly now.  Even our disks have built in encryption.  That's what I mean by security encompasses everything and should almost be the foundation that we build the architecture on.

Lesson 04: The Enterprise Technology Infrastructure Architecture

The Technology Stack is without a doubt my favorite part of EA.  It is what I like doing the most and what I spend most of my work time on.  Currently I'm involved in 2 projects in this area.

The first is mapping in significant detail our current EA.  While this goes against the best practices and the thoughts of EA it is a requirement at my place of work.  Every few years we have to be reaccredited with the DoD.  This time is a little different because the way that the DoD tracks, accredits, and issues ATO's (Authority To Operate) has changed.  Spending this much time on the current state can be annoying it has brought out a few interesting things that would be somewhat like Gap Analysis.  It has also spawned a lot of discussion about where are future state is going.  And a lot of long useless meetings arguing over semantics, like the definition of "Platform".

And thats where the second project comes in and the one that I'm really enjoying.  Defining the furture state of the actual technology is a lot of fun.  I have a tremendous amount of latitude because of a lack, and by lack, I mean non-existant, of IT Governance.  Robertson's article at Gartner suggesting that ETA should not be concentrated on until other parts of the EA process are complete rings very true.  There are some cases though where pieces of it need to be defined early.  In my case a large majority of the applications in the environment are custom applications developed by us.  So certain aspects need to be defined.  Without getting into the politics too deep, we have "heavily suggested" the use of certain core services to build the applications on (we are not allowed to define, or call them standards).  For example the "preferred" relational database service is PostgreSQL.  Web servers should be either Nginx or Apache.  Messaging Services should utilize RabbitMQ, etc, etc.  Try as I might to follow the Best Practices, which I really feel they are, I am constrained by the way the DoD operates.  So due to some of the constraints and the way things operate, I'm bound by "requirements" or "stakeholder concerns" too much.  Since my primary role is RDT&E (Research, Development, Testing & Evaluation) I get dive into the ETA head first.  Since I do work closely with other groups I do try and come up with "requirements" to form my projects and their direction so that what I'm doing is seen as valuable to stakeholders or would-be/potential stakeholders or others in positions that could impact my work.  I try to use the tools and technologies they are interested in or are using (especially if I'm doing a Proof of Concept) currently.  It's a very strange world I work in sometimes and the politics can be annoying.  Again though, I get to dive head first into ETA without a lot of constraints.

I do agree with the Best Practices though and have seen a project at another organization not contrained by the DoD, crash and burn because some of these weren't followed, as well as some of the issues from Robertson.  Like not having the project and technology aligned with the business and its needs.  Another big one was "Stakeholder concerns not adequately defined".

Over all, ETA is very important.  How and when it's done really depends a lot on the company and how they operate.  It also needs to be done in a layered, iterative approach starting with higher level technologies and then drilling down.  It also needs to be documented at differently layers and levels from the high level overview for less technical people down to almost packet flow for the highly technical people.  And as always, security should be one of the major considerations and one of the first layers to be defined.

Lesson 03 - Data Architecture

Shooting from the hip, as I generally do, a few things jump out at me from just the summary page.  When building an Enterprise Data Architecture there are several other things that need to be considered.  I generally think of the hardware and software solution aspects because that is my background and what I love most about this.

As I said, there are a lot of things to consider when dealing with Enterprise Data Architecture.  I look at it from this way, in no particular order (at least not yet).

• What needs to be stored vs. what needs to be just processed and utilized?
• What departments need that data and does any/all of it need to be shared with other departments?
• If data is shared, is the original data seen or just the results?
• Who is responsible for the data?
• What is the level of security on that data?  Is it PII?  What security controls need to be on it and are those security controls transferred to other groups/departments/vendors/suppliers/etc?
• How long does the data need to be stored
• How fast does the data need to be accessed (this is the Solution Engineer in me)

These are just a my initial thoughts and some of things I go through or think about when dealing with Data Architecture.  It can honestly be a VERY slippery slope and difficult area, especially once you start diving into the technical aspects (again, my favorite part).  Online/Near-line/Offline storage.  SSD/Hybrid/Spinning/Optical storage.   Data at rest encryption, Data in transit encryption, open standards, hardware standards, physical media standards, physical storage, etc, etc, etc.

Lesson 2 - Initial Thoughts

Lesson 02: The Enterprise Application Architecture 

    Going to take this in a little different direction.  I think my first post under each lesson topic will be just an off the cuff post about my initial thoughts on the topic from the readings based on just my experience and thoughts.

So, Enterprise Application Architecture:

    This is one of the pillars of Enterprise Architecture.  There are a whole slew of applications that are required to make a business or organization run.  One of the aspects of creating an Enterprise Architecture is analysing the current architecture and searching for gaps and redundancies.  Those gaps and redundancies are generated from a number of different events.  In most cases it comes for mergers and acquisitions.

    The value of Enterprise Application Architecture aligns with the value Enterprise Architecture as a whole very well, hence why it is one of the pillars of it.  That value is derived from the standardization of applications for the enterprise. This allows for lower costs from things such as licensing, administrative overhead, and training.  It can also have an effect on security by limiting the amount of software products that have to be tracked for things like security patches, etc.  Another benefit and value of a well defined Enterprise Application Architecture is the ability to make more efficient use of data in the Enterprise.  This is mainly seen in the sharing of customer data to not only provide better customer service but for things like targeted marketing.

    One of the difficult aspects of Enterprise Application Architecture is getting everything to work together.  That is the goal of ERP, which often misses the mark.  And now with the proliferation of hosted services you are seeing more and more companies outsource certain pieces of their enterprise applications to 3rd party vendors.  Also with the expansion of telecommuters, offsite employees, and BYOD (Bring Your Own Device) a lot of these Enterprise Applications are becoming web services, security becomes an even bigger concern.  The plus side of them becoming web services though is the lack of specialized software that has to be loaded.