Topic 5: Enterprise Security Architecture

Reflection 1: 9 Stats IT Should Know on Sensitive Data Stored & Shared in the Cloud

As a law firm, my employer maintains a large amount of personally identifiable information (PII) along with vast amounts of our client’s (banks and lenders) data and digital documents.  Our desire to move as much of our datacenter to the cloud (along with all this sensitive data) as quickly as possible has led to many debates about PII and sensitive client data in the cloud.  These debates have to consider the regulations governing the mortgage industry (our area of practice) and law firms along with our client’s wishes and demands.

With this reality in mind, I wanted to dig deeper into the world of encryption for data stored in the cloud, which brought me to the above article for my first reflection.  This article offers several fascinating statistics and insights regarding the lack of security around cloud storage.  This particular article focuses on cloud-based applications and how few application service providers encrypt their user’s data at rest and how much sensitive data users actually upload.

The problem that I’m more interested in is with cloud-based file system storage.  When offerings like Google Drive or Dropbox are examined, we see that they encrypt user data at rest, but the rub is that the user does not control or possess the encryption key(s) - Google and Dropbox handle that.  Would this be good enough when it comes to ensuring our clients (and regulatory bodies) that their data is safe?  I don’t think so.

The only way we, or any other organization, as caretaker of sensitive information, can promise anyone that the data is safe is if it’s encrypted at rest and we control the encryption keys, not a third-party.  Even if the likes of Google and Dropbox have better security controls than my small-to-medium sized law firm, they are still a third-party - no assumptions can be made and no assurances can be granted for their capabilities.

After a quick look at Amazon’s AWS offering for cloud storage, I saw that they offered encryption at rest (no surprise) along with the option for the customer to control the encryption key(s).  I’m not sure what the banks think, but if their data is encrypted and we possess the keys, then it simply shouldn’t matter where the data is actually stored.

Reflection 2: 4 fatal problems with PKI

I couldn’t help reflecting on this article, because, as technology-oriented articles go, this one is quite sensational.  Actually, the first three flaws are more mildly surprising than sensational, at least for someone who is not a security expert.

The first flaw essentially says that PKI is too complicated and thus prone to mistakes.  This is a perspective I was not aware of, as many companies set up their own PKIs and apparently, most do it poorly.  Of course, the article is written by a PKI consultant, so he obviously stands to gain by convincing businesses that they cannot set up a PKI themselves.  

The second flaw is an extension of the first, where the author states that the complexity of PKI causes numerous PKI errors that often reveal themselves to a user trying to reach a supposedly secured website.  In a more secure Internet, the errors would be few and when there are PKI errors, access would be blocked.  However, what happens in the real world is that our browsers allow access, presenting nothing more than a warning, which is usually ignored by the user.  

The third flaw really isn’t a flaw of PKI at all.  To impune PKI by stating that it does address all other technology security risks that a business faces doesn’t make much sense.  PKI is primarily used as an integral component for encrypting data in transit, and with the exception of flaws one and two, it really does that quite well (and has been doing it for quite some time also).   

It’s the fourth flaw that I found extremely interesting, very sensational, and somewhat scary.  For the fourth flaw, the author states that “eventually, PKI will stop working forever”.  One of the few things I know about PKI is that it’s based on asymmetric key pairs, where a file encrypted with key “a” can only be decrypted with key “b” and vice versa.  Knowing the key used for encryption does not allow someone to decrypt the file, which is the fascinating point about this technology (developed back in the 1970s).  The secret to asymmetric key pairs involves large prime numbers and some very complicated math, so complicated that even today’s computing power cannot be leveraged to crack the encryption keys.  However, here is where the author makes it interesting.  He says:

One day, the incredibly hard math involving large prime numbers won't be so difficult to solve anymore.  For example, one of the biggest promises of Quantum computing, whenever it finally gets perfected, is that it will be able to immediately break open PKI-protected secrets. Sometime in the near- to midterm future, useful Quantum computers will become a reality. When they do, most public crypto will fall.

After delivering the depressing message that the very foundation of a secured Internet will one day crumble, the author at least offers a modicum of hope by saying that quantum cryptography will be the answer.  The author then steals back that modicum of hope by stating that the quantum computers needed for quantum cryptography will be extremely expensive and beyond the means for the average Internet user.   

Hard to tell where this is headed, but if there’s any likelihood to the author’s claims, then I would guess that in the future we might be shopping Amazon from some centralized Internet cafe offering quantum computers, at least until we can afford our own.

Reflection 3: Quantum computing 101

I wasn’t expecting to reflect on quantum computing, but the previous reflection proved too fascinating to just drop the topic.  Even though there’s a lot of interesting material in this article and it’s presented in a nice “101” manner suitable for someone reading about quantum computing for the first time, what’s really nice is that it explains how quantum cryptography works, at least at a high-level.

Rather than trying to summarize an already nice summary, I’ll call out a few of the interesting elements of quantum cryptography.  The first interesting element is that the encryption key is based on the polarization of photons, which is completely random and unpredictable (crazy quantum stuff).  What’s really interesting about this is that the “key” is physical in nature, unlike today’s keys which are based on a mathematical problem.  Because of this physical (and random) nature, even the most powerful quantum computers of the future will not be able to break the key because it’s not mathematical.

Even if the keys cannot be cracked, one would think they could be intercepted in transit, which is another really interesting part of quantum cryptography.  While the photons are being transmitted to the parties wishing to initiate encrypted communication, they cannot be sniffed or copied in anyway, as such an innocuous action will cause their polarizations to randomly change (more crazy quantum stuff), causing the keys to not match, and thus, forcing the two parties to retry until their keys match.

The last interesting point about all this crazy quantum stuff is that for the field of cryptography, it is simply a new means for distributing synchronous keys (shared secrets).  Once the quantum distribution of photons has successfully been concluded, everything reverts back to technology we are all comfortable with today, that being traditional data encryption using a shared-secret key.  As long as those photon-generated keys are not stored and reused, all communication should be secured.

What I don’t understand at this point is who will generate these photon-based keys and how will they be transmitted to the parties involved.  Will it be technology for the masses or for the few?  Will the average Internet surfer be required to own a quantum computer to receive a quantum key?  The author from my second reflection implied as much when he expressed concern that quantum computers are not expected to be priced for the average consumer anytime soon, if ever.  

This leaves me wondering what the future of e-commerce and B2B integration looks like.  It sounds like there’s going to be a period of time in which a small number of quantum computers will exist for big business, governments, and James Bond villains, while unavailable to the rest of the world.  This means that traditional Internet encryption using PKI could be easily cracked by anyone possessing a quantum computer while the masses will not yet have access to quantum keys as the antidote. That sounds scary and certainly would be a huge step backward.

Topic 4: Enterprise Technology Infrastructure Architecture

For this week’s blog posting I’m going to reflect on operating a data center as well as some of the current trends impacting data centers. A couple of blog postings ago I wrote about how SMBs are anchored down by maintaining their own data centers, stunting progress with the core business and other areas of IT such as SOA implementations and analytics, so it seems worth exploring data centers a bit deeper.

Reflection 1: As it shuts its final data center, for Netflix it’s all about the CDN!

For my first reflection, I wanted to find a real-world example of a business moving entirely to the cloud, ideally an SMB.  In my research, I came across this article from last year on how Netflix finished moving its entire business to Amazon’s cloud platform.  Netflix is far from an SMB, but the article was too compelling for me to ignore.  

The second paragraph immediately answers the important question of “why?”.  In 2008 Netflix experienced a serious outage with their data center, which is probably the primary impetus behind most cloud migrations, especially for SMBs where, I believe, proper investments in reliability are lagging.  Many businesses will examine the costs and benefits and cautiously contemplate a move to the cloud, but as soon as there is an outage, that cautious contemplation quickly becomes an irrepressible demand, which speeds matters up.  

The article, unfortunately, doesn’t provide any cost comparisons between the Netflix operated data centers and the cost of operating in the Amazon cloud, but direct, measurable costs are probably not going to be the deciding factor.  It’s going to be the indirect costs associated with outages that will be the deciding factor, along with the realization that running a data center is simply not a core capability of most businesses.  Focusing on the core and offloading or outsourcing most of the rest is a common and sound strategy these days.

The only piece of their home-grown infrastructure that Netflix did not move to Amazon’s cloud was their content delivery network, which essentially consists of all the video caches around the world, allowing their content to be close to the customer.  There are plenty of edge computing companies, including Amazon, that could handle this for Netflix, so one can only assume that Netflix considers their content delivery network a core capability and competitive advantage - something they do better than others - while the rest of the IT infrastructure was not.

   

It’s ironic to note that as I was writing Reflection 3 (below), Netflix had a serious worldwide outage for at least one hour.  It would be interesting to know if it was Amazon’s doing or something self-inflicted by Netflix.  Regardless, I don’t think Netflix will be reversing direction any time soon.

Reflection 2: Details on Google’s massive cloud infrastructure revealed

In looking for articles on data centers and moving to the cloud, this article, while not providing insights on the value of moving to the cloud, was still too interesting to ignore.  I’ve always marveled at Google’s ability to do what they do, especially given the performance problems of the small, custom-built application that manages the back-office operations of my current employer.

What amazed me was the revelation that Google now designs their own hardware to address their unique performance and load requirements rather than use commercially available options, which Google deemed unsuitable for their needs.  

At first, I was curious why Google hasn’t commercialized their networking/hardware innovations, but I quickly concluded that they must consider such innovations a competitive advantage and, as such, choose to keep their technology private.

More importantly, I wondered how networking giants like Cisco could be out-innovated in their core area of expertise by a company who’s core is not in networking and hardware. Is it because commercializing hardware and software for a mass-market requires compromises in order to achieve certain cost and utility goals?  I’m going to assume Cisco knows how to do what Google did and probably figured it out before Google did.  Cisco must have concluded that the capabilities were too specialized and/or too expensive for the commercial market - if I were to give them the benefit of the doubt.

Conversely, it could be that Cisco is withholding innovations that would disrupt their own market segment.  That’s not unheard of, albeit very risky, as I have to believe there are numerous other potential disruptors, that unlike Google, would be happy to commercialize such innovations.

Reflection 3: Why Hyperconverged Infrastructure is so Hot

One of Google’s innovations (from the previous reflection) was to build software-based switches using cheap hardware.  This sounded very similar to the recent trend in data centers called hyperconvergence, which is the third article I want to reflect on.

The hyperconvergence trend simply takes the software-based virtualization paradigm for compute environments and adds storage to the mix.  This allows data centers to simplify and further extend the cost savings and flexibility that virtualized compute environments have long delivered.

The article compares and contrasts the hyperconvergence trend with its convergence predecessor.  Both trends try to commonize on hardware, however, the convergence trend still saddles a data center with separate storage and compute devices, which in turn, requires an emphasis on expensive networking hardware.  By contrast, hyperconvergence melds storage and compute platforms together, managing them from the same software-driven virtualized environment, in turn, deemphasizing the network and the need for expensive networking hardware.

It is interesting how strong a resemblance the hyperconnectivity trend bears to Google’s data center innovations from Reflection 2.  In Reflection 2, I pondered why Cisco (or others like them) hadn’t beat Google to the punch with such software-driven data center innovations.  One of my speculations was that it might be too disruptive to their lucrative market.  I find it interesting that hyperconvergence, with its emphasis on virtualized storage and compute environments and the de-emphasis on networking, seems to support that speculation.  There should be no need for the networking giants to worry though as I’m sure the Internet holds plenty of opportunities for growth.

Topic 3: Enterprise Data Architecture

Reflection 1: The Six Principles of Modern Data Architecture

The first article I want to reflect on lists the six principles of a modern data architecture.  I almost dismissed this article as a list of banal bullet points which we have seen many times over. However, it was the last bullet point (#6 Eliminate Data Copies and Movement) that grabbed me.  

I’ve always focused on establishing single points-of-entry (into the enterprise) for critical data entities.  Once these single points-of-entry are established, a robust SOA can allow the rest of the enterprise to request the data, rather than creating redundant data capture capabilities which always lead to data inconsistencies throughout the enterprise.  

My thinking also assumes that systems requesting data from the point-of-entry system(s) will store the data locally for performance purposes.  Even though the data will be replicated, at least it will be single-sourced and consistent.  It is that very assumption of mine that made principle #6 so compelling.  It’s a great vision, eliminating data redundancies and movements, but has technology progressed enough to make it a data architecture principle that all enterprises can adopt?  

The same observation was noted in Andrew Richard’s blog posting from September 11, 2016, where he notes the usual and customary approach of replicating data for performance purposes, even when a robust SOA is available to share data.  Mr. Richard goes on to ask if there are any good reference architectures that address the replication problem.  The short write-up for principle #6 mentions a product called Hadoop which I had never heard of before and which is where my second reflection is headed toward.

Reflection 2: Running Operational Applications (OLTP) on Hadoop...

After Googling “Hadoop” and reading various articles, I quickly learned that it is an open sourced, big data platform.  I will admit that I am not well versed with the big data trend.  My high-level understanding is that it is largely pertinent to data warehousing and analytics.  However, for the question raised in Reflection 1, what I’m really interested in are traditional relational databases used by OLTP applications.  Can Hadoop (along with a compatible RDBMS) and big data reach beyond the data warehousing and analytics world and solve the replication problem in the OLTP world?  Can a business actually have a single “big data” OLTP database serving much, or maybe even all, of the enterprise?

Those questions brought me to the second article I want to reflect on.  This article asks and answers four different questions about Hadoop.  The first question sets the stage quite well...

Hadoop is primarily known for running batch based, analytic workloads. Is it ready to support real-time, operational and transactional applications?

This is exactly what I want to understand, so let’s look at the second question which asks how enterprises can take advantage of Hadoop.

How can enterprises, specifically in the Retail industry, take advantage of a Hadoop RDBMS?

The author responds to this question with a scalability and performance answer, stating that enterprises can leverage Hadoop and Splice Machine (Hadoop-compatible RDBMS) to provide scalability and performance for extremely large RDBMSs.  So, scalability and performance is examined while eliminating data replication and movement is not.  My hope that this article was going to address principle #6 from my Reflection 1 article seems very much in doubt now (even though principle #6 specifically mentions Hadoop).  Let’s take a look at the third question.

Can we run mixed workloads – transactional (OLTP) and analytical (OLAP) – on the same Hadoop cluster?

Now I see how this article is addressing principle #6 and why Hadoop was mentioned in the first place.  Remember principle #6 is titled “Eliminate Data Copies and Movement”.  I immediately interpreted that as a call to eliminate redundancies between OLTP databases and the movement of redundant data between OLTP databases.  However, this third question reminds me of the more likely intent, which is the elimination of data redundancies and movement between OLTP and OLAP environments.  I don’t know if that’s what the first article had in mind with principle #6, but I think it is.

The fourth question simply explores the return on investment for implementing a Hadoop/Split Machine solution for massive RDBMs that mix OLTP and OLAP capabilities.

Even though article 1 was not specific in what it meant by principle #6, and even though article 2 did not actually explore the possibility of some enterprise one day building a single enterprise-wide OLTP database, I can’t help but think the enabling technology exists with Hadoop and Split Machine - the biggest challenge with such a crazy concept will likely be organizational.

Reflection 3: Do You Know What Your Company’s Data Is Worth?

The third article I want to reflect on shifts gears to a different topic, which is treating data as an asset.  Among the Lesson 3: Enterprise Data Architecture reading material for EA-874 is an article from Gartner titled “Managing Information as an Asset: Enterprise Architects, Beware!” which describes this “information as an asset” concept as treating your data with care, ensuring consistency, accuracy, accessibility, utility, safety, and transparency. Upon reading the title, I felt I wanted to include the article among my three reflections.  Upon reading the article itself, I no longer felt it was worth reflecting on - businesses needing to treat their data with care like it’s an asset seemed too obvious and not very interesting.

However, just a few days later I came across the Reflection 3 article from above.  This article actually does talk about assigning a dollar value to a company’s data, which is a new and interesting concept, and one I want to reflect on here.  

My initial position is that data valuations don’t belong on the balance sheet as its value is already reflected in intangible asset categories such as goodwill, brand equity, and intellectual capital.  However, what I learned in reading the article is that this idea of valuing data is not about adding new assets to a company’s balance sheet, but is instead about taking the intangible assets valuation and breaking it down further to assign a chunk of that valuation to the company’s data.

The important realization for me is that the total value of intangible assets will still be calculated in their traditional ways.  Here is a very simple approach:

Intangible assets = market capitalization - (year-end sales + tangible assets)    

The article isn’t saying businesses are now expected to mess with their balance sheets and inflate them with valuations of the data they possess.  It’s simply saying that businesses need to take their intangible assets valuation and figure out how much of that valuation is attributable to their data.

So why is this important?  The answer is risk management.  The higher the data valuation, the greater the exposure to such things as cyber attacks and system outages (such as Delta Airlines recent outage).  Once investors, business leaders, and IT leaders have a clearer picture of risk exposure, then, it stands to reason, better decisions will be made to mitigate the exposure associated with safeguarding a company’s data.

Topic 2: Enterprise Application Architecture

Since the topic for this blog posting is Enterprise Application Architecture and since the title of this blog is Enterprise Architecture for SMBs, it seems fitting to analyze one of the critical elements of an Enterprise Application Architecture, that being SOA, for small and medium sized businesses.

Reflection 1: Small and medium businesses: We simply don't need SOA

The first article which I want to reflect on explores the position that SOA isn’t necessarily important for SMBs.  The reason offered is that SMBs do not have the application complexity and diversity that large enterprises have.  I currently work at a $60 million business which has two primary lines of business.  Each line of business has a primary back-office system (one is custom-built, the other is commercial) along with shared commercial finance and CRM systems.  That’s about it - definitely not complex, so the article has my attention.

The article references an informal survey of mid-market CIOs which reveals that two-thirds feel there is no business need for SOA at their enterprise.  This opinion may be due to an overall simpler IT environment that “works” or it may be due to limited resources (people and budget).  Whatever the reasoning is among these CIOs, I think the informal survey provides an accurate representation.  The article is from six years ago, but having worked at SMBs for the past nine years, I think the opinions expressed in this 2010 article are still holding true in 2016.  

Further into the article, however, the author chooses to pivot from the opinion of the mid-market CIOs and offers some of his own reasoning on why SMBs should care about SOA.  He says:

Of course, the mid-market is the prime candidate for cloud computing, and this is where the value of service orientation will ultimately be realized, on an enterprise-to-enterprise scale. But for applications within the infrastructures of smaller enterprises, SOA is still beyond reach.  

Still, the more a business of any size can service orient, the better. SOA is an extension of enterprise architecture, and EA is important at any level.

I’m in agreement with the author and I think the first paragraph above is very telling.  Even six years after this article was published, I can attest that for many SMBs, running a solid, well-managed data center is beyond their capabilities.  With the data center yoke around our necks, the notion of implementing a service-oriented architecture is accurately stated as beyond our reach.  We need to get out of the data center business, move to the cloud, and then start innovating with our Enterprise Application Architecture.

Reflection 2: How Can Small to Medium Sized Enterprises Benefit from SOA?

For my second reflection, I want to remain on topic with SOA at SMBs and get some additional perspectives on why SMBs can, and should, move to a SOA.  The article being examined is actually a series of responses to the question “How Can Small to Medium Sized Enterprises Benefit from SOA?”.  Most of the answers lack substance and depth, but there were a couple of comments that I found very relatable.  In the posting from John Power he states the following:

However, from my perspective the real benefit to SMBs is the possibilities it offers them to integrate their systems with large customers or suppliers.

This struck me in two ways.  First, it struck me for its accuracy.  It has been my experience that invoking a few web services and standing up a few of our own in order to integrate with our suppliers and partners is exactly what many SMBs do for their SOA initiatives (without going much further).  

The second manner in which it struck me was how it reinforces the confusion and hype around SOA.  Integrating with a handful of external businesses through web services in no way constitutes the deployment of a broad service-oriented architecture.  However, I will state that those simple external integrations are extremely valuable to SMBs and they work well, leading many CIOs, I reckon, to conclude “that’s good enough for us”.

The other posting that caught my attention was from Kelly Emo.  She states the following:

Secondly, SMBs will find themselves brought into the SOA world whether they explicitly plan for it or not. Packaged apps and SaaS solutions are rapidly evolving to be architected based on the concept of loosely-coupled shared services...

This claim is also very accurate in how it matches my SMB experience.  It is the packaged applications and SaaS solutions which SMBs utilize, that essentially forces them to eventually learn and leverage the service orientation built into those commercial offerings.  

It seems the ultimate takeaway for me is that SMBs will adopt SOA gradually (even glacially) and very deliberately, avoiding big-bang transformations.  If resistance persists, then, to the point made by Kelly Emo, SOA will likely start deploying itself in the enterprise.

Reflection 3: It's Time to Retire the Concept of the Three-Tier Application

The third article I want to reflect on comes from the Lesson 2 reading material for EA-874.  This article seemed like it would be a fitting cap to my SOA-themed blog post.  I expected the article to largely espouse the virtues of service-orientation for building applications. In other words, the author just wants us to replace the traditional locked-in business logic of the middle tier with services that can be invoked throughout the enterprise.

The author quickly reminded me, however, that replacing the locked-in middle-tier with services still leaves us with a three-tiered application.  So, my assumption about the article was wrong and I was suddenly wondering what new trend all the SMBs will be lagging behind on now.

It turns out the author is not actually recommending that we retire the three-tiered separation of concerns between user interfaces, business logic, and data access.  He, in fact, states that we need to continue reinforcing the three-tiered separation of concerns.  All the author is saying, as a natural evolution after implementing a SOA, is that the user interfaces of applications should no longer be homogenous and monolithic - they should be a collection of components supporting many devices.   These user interface components will invoke many business services, and these business services will invoke many data services.  

Keep in mind that all these pieces are still to be architected with the separation of concerns being resolutely applied.  We just need to stop thinking about single applications as a homogenous three-tiered stack and instead start thinking about them as a collection of user components and business services that cannot be easy abstracted as a nice, neat three-tier stack.

The bottom line is that the separation of concerns (user interface, business logic, data access) is not going away, but simple, self-contained applications are. All in all, not too big of a paradigm shift for SMBs to work toward...once we start making more progress on our SOAs.

Topic 1: Enterprise Information Technology Stack

Reflection 1: On layers in enterprise-architecture

Since the first lesson for EA-874 is an introduction to the enterprise architecture stack, I thought it would be worth taking a closer look at the different stack depictions among EA frameworks.  The above article highlights a few of the differences:

• Archimate’s three layers: Business, Application, and Technology
• TOGAF’s four layers: Business, Data, Application, Technology
• Zachman’s five or more layers (depending on interpretation)

In addition to the article, our Lesson 1 reading material falls in line with TOGAF, while the Gartner EA framework (not examined in the article) puts a twist on the stacked layer paradigm, emphasizing the business, data/information, and technology layers.  Instead of stacking them, Gartner shows the layers intersecting, and it’s at the intersection of the three layers where solutions (applications) are defined and created.

The article rightly points out that while there are many depictions of the EA stack, two layers are consistent: business and technology.  It’s the data/information and application layers that provide the variability.  

While the article fairly contends that there is no right or wrong depiction, I will express a bias for having a data/information layer that is separate from the application layer.  Information should be treated as something that exists in an enterprise regardless of the existence of applications.  It’s for this reason that an information layer is essential to defining an enterprise.

I will further express a bias for the Gartner approach, which shows applications (solutions) not as an EA layer, but rather, as an outcome of the three core layers of business, information, and technology.  The business and information layers should define the enterprise without regard for technology.  When we add in the technology layer, we now have the ability to create solutions and/or applications.  It is the three layers of business, information, and technology that actually define the enterprise.  Once they are established the enterprise can go about creating solutions/applications.

That’s just my point of view.  Once again, there can be no right or wrong, just varying degrees of acceptance or popularity.

Reflection 2: Introduction to Enterprise Architecture

The previous article explored the long-standing differences in EA stacks and their respective layers.  This article goes a bit further and reveals a recent trend for depicting separate security and integration layers, not as part of the stack, but as vertical layers that touch all the horizontal layers of the EA stack.  

I have an easy time seeing why security is being treated as an EA layer, albeit vertical, as all EA layers have unique security requirements which are not all technology-driven, and thus, not addressed in the stack’s technology layer.  Security strategy should be expressed and executed at an enterprise level to ensure that all layers of the enterprise are addressed in a coherent manner.

The integration layer, however, is something I’m still struggling with.  I see integration as part of the technology layer, used to build solutions and enable communication between intra- and inter-enterprise applications.  I’m not sure what the purpose is at the business and information levels.  Keep in mind, my interpretation of the information layer is as a logical depiction of the enterprise’s information without regard for applications, which is why I struggle with the integration layer having pertinence here.

It will be interesting to further explore vertical EA layers throughout the semester as well as in the following article and reflection, where yet another example of a vertical EA stack layer is presented.

Reflection 3: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture

In this last article, the author took four real-world businesses and mapped their actual EA layers to the author’s proposed, or ideal set of EA layers.  The four businesses were intentionally selected from different business domains and different countries to ensure diversity.  

One discovery, maybe not that surprising, is that each business had implemented their own unique layering, definitions, and core artifacts, which can be seen in the respective diagrams depicting the mapping between the subject’s layers to the author’s proposed layers.  The paper is only two and one-half years old (published in February 2014), so it’s interesting to see the custom EA programs at these businesses given the amount of time the more popular EA frameworks have had to take root.

On the surface, these differences don’t seem to mean much as they appear to be mostly superficial preferences in naming and in the grouping artifacts and responsibilities.   It is interesting to read the motivating factors each business had for starting their EA program and to contemplate the impact those motivators had on the resulting custom EA layers and programs even though the article avoids direct cause and effect conclusions.

Let’s take a quick look at how these four real-world EA stacks compared to our Lesson 1 reading and the first two articles from above.  

• Company A comes close to the common three layer stack, forsaking the data/information layer but adding the strategy layer, which I think most EA programs would lump into the business layer.
  
• Company B comes very close to the traditional (and Lesson 1 recommended) four layer stack, but surprisingly, separated out the data/information layer into two separate layers, treating the data layer in the traditional sense of logical and physical data models, while defining the information layer in a unique fashion with a focus on metrics.  
  
• Company C really went custom with six layers.  What I found interesting here is the integration layer, which is depicted in the stack as a horizontal layer underneath the application layer.  Recalling the second article from above, where I was having a hard time with the notion of a vertical integration layer spanning the entire EA stack, this approach by Company C made more sense to me and felt much more intuitive.

• Finally, Company D went with the traditional three layer stack, but also added in two vertical layers, similar to what was depicted in the second article.  One of these two vertical layers represents security, matching the reference from the second article and further reinforcing the concept of a vertical security layer as a trend with EA stacks.

My take-away from all this is that businesses will commonly tailor their EA stack, just as the article’s four companies did, even as certain EA frameworks gain wider adoption.  This tweaking will sometimes be done in obvious ways, by adding or subtracting layers, and also by more subtle ways, by slightly altering the definition of certain layers and what artifacts and responsibilities get grouped into those layers.

Ultimately, the differences come down to each enterprise simply wanting to emphasize unique EA elements while deemphasizing others based on their unique histories and future strategies.

Agile Leadership

The “agile” label has been used heavily in the software development world for many years and is now in vogue for businesses and IT/EA governance programs (and many other disciplines, I’m sure).  This label is meant to describe a trait that all businesses or organizations aspire to be  - responsive, fast, nimble, or in a word...agile.  In essence, “agile” should be as much a leadership philosophy as it is a governance or software development methodology.  If we want our EA programs and our governance programs to be agile, then it’s going to come down to the people - the leadership - to make it happen.  So, what is agile leadership and how is it achieved?

Agile leadership is essentially the antithesis of bureaucracy, and it involves the blending of three major leadership functions that typically suffer in a bureaucratic world; setting expectations, empowerment, and accountability.

• Expectations – What are the results that you or the organization want to achieve? Know what they are and state them.

• Empowerment – Do you have talented, experienced, responsible people?  If so, then allow them to make decisions without seeking approval.  That’s what empowerment is.

• Accountability – If your people know their expectations and are empowered to make decisions, then they must also know they will be held responsible for their decisions.

There may be nothing that will allow an organization to better achieve agility, speed, and responsiveness than the simple actions of setting expectations, empowering the right people, and then holding them accountable.  It also stands to reason that few things will give the people being empowered greater satisfaction. It’s worth pointing out here, the research Frederick Herzberg did regarding job satisfaction (Herzberg, F., 1987) where the top four factors leading to job satisfaction were 1) Achievement, 2) Recognition, 3) Work itself, and 4) Responsibility.

The most important thing to understand about bureaucracies is that they are not out-of-control, uninvited party crashers that ruin businesses.  Rather, they are structures intentionally put in place to achieve a very specific objective – to make sure bad decisions are not made.  The benefit would be great if the costs were not so high.  The price of this desire for near perfect decision making is that large chunks of time are consumed and there is almost no accountability.  When decisions are finally made, after multiple reviews and through the seeking of consensus, the amount of time elapsed often renders the decision irrelevant (or weakened, at best).  Also, who’s accountable?  The answer is largely no one; and when nobody is accountable, progress tends to not take place.

Unfortunately for many, forsaking the stifling and unaccountable safety of the bureaucracy feels risky.  However, for an organization with talented, experienced, responsible people, the risk is easily mitigated.  These people know what needs to be done and how to do it, so to confine them to a bureaucracy is really an absolute shame.  If an incorrect path is taken the sheer speed with which it is taken will usually soften the impact significantly.  In other words failing fast is a lot better than failing slow, or failing through inaction or atrophy (which is the most common outcome of bureaucratic structures).  As agile EA leaders, all we have to do is know our people and empower the right people – the upside in speed and agility, not to mention job satisfaction, will be tremendous.  

References

Herzberg, Frederick.  (1987, Sep-Oct).  One More Time: How Do You Motivate Employees? Harvard Business Review.   Retrieved from http://scholar.google.com/scholar_url?url=https://xa.yimg.com/kq/groups/22741279/1871431599/name/One_more_time.pdf&hl=en&sa=X&scisig=AAGBfm1uUvvj1BuLUUxfm4pTEoVgU2GfjA&nossl=1&oi=scholarr