Topic 7 – Evaluating Emerging Technologies, Innovations & Trends

Post 1 – The Internet Of Things Needs Enterprise Architecture

I think this article makes a good argument for EA playing a pivotal role in the success of the Internet Of Things (IoT). For example, “As with most dramatic shifts in technology, unfortunately some businesses will be lost, unable to transform and cope with new consumer demands. That’s why solid enterprise architecture foundations are so important, and potentially the difference between a business floundering in the face of change, or flourishing.” (Zak 2015)

Cole, Zak September 9, 2015 https://www.corso3.com/blog/the-internet-of-things-needs-enterprise-architecture-behind-it

Post 2 – How Enterprise Architects Should Encourage Innovation

For me, this article explained the crux of the issue when IT and Business collide. “Ideas that come from business partners tend to focus far more on solving business problems or quickly capturing business opportunities because they instinctively apply their knowledge of customers, competitors, and processes to generate innovative ideas.” (Bergsman 2015)

Bergsman then goes on to explain how through Enterprise Architecture, the organization’s IT and Business departments can work together to foster innovation.

Bergsman, Jeremy May 20, 2015 https://www.cebglobal.com/blogs/it-how-enterprise-architects-should-encourage-innovation/

Post 3 – Where do we go from here?

I found this to be a really well written narrative of the typical attempt of an organization to implement EA. It then goes further to explain how to take it past the point of typical failure and succeed. I think the biggest takeaway is IT and Business need to work together, always, on the company’s strategies. If at any point the two work independently, then EA will most likely fail.

Topdjian, J., Klemm, D., & Drisko, C. (2016, February 3). Enterprise Architecture Planning 2.0. Retrieved April 24, 2016, from http://www.strategy-business.com/article/Enterprise-Architecture-Planning-2.0?gko=43bf5

Advertisements

Topic 6 – Understanding the Emerging Business Architecture Layer

Post 1 – BUSINESS ARCHITECTURE MUST EXPAND BEYOND ORGANIZATIONAL BOUNDARIES

An interesting Forrester article from 2015 posits (perhaps optimistically) that by 2020, businesses will utilize the Business Architecture (and therefore the business architect) to expand outside the boundaries of the organization as a strategic advantage. While that prediction may or may not come true for the majority of businesses, I do believe the article in spirit is right on.

“[T]oday’s business architecture addresses strategy, capabilities, knowledge, and structure from the organization’s own point of view and boundary constraints, in an extended business architecture in which the organization operates, BA will address these concerns from the points of view of the customers, suppliers, regulators, employees, and partners — the industry model.” (Barnett et. al, 2015)

I think the above passage really sets the tone for  what is needed to become proactive in any industry, and is exactly what the board, investors, and other key stakeholders are really looking for.

Gordon Barnett with Alex Cullen, Alex Kramer, Diane Lynch, 2015 https://www.forrester.com/report/The+Future+Of+Business+Architecture+Developing+CustomerDriven+Business+Models/-/E-RES95381 (note: use PSU Angel site to log into the Forrester Database through the Library link to view this article)

Post 2 – Does the traditional idea of Business Architecture work with Agile?

This is an interesting post on the idea that perhaps the classical ideology behind Business Architecture doesn’t fit well with more agile and free form schools of thought. While Business and Enterprise Architecture ideologies have had their fair share of criticisms over the years, I don’t think they’re precluded from being successful ideologies within an Agile driven world. In fact, I think they are more important now than ever before.

David Winders, September 9, 2015 https://www.linkedin.com/pulse/agile-business-architecture-conflict-tension-david-winders

Post 3 – Agile is NOT a reason to not do Business Architecture

With any new ideology or methodology, people tend to take them as whole sale replacements for the “old”. In reality, new ideas tend to enhance the old more than they can replace them. This article is an excellent description of why Business Architecture isn’t going anywhere, and can enhance Agile methodologies rather than be replaced by them.

“Once in place [referring to Business Architecture processes], Agile experts can use their business architecture model to link their requirements and processes to capabilities and values among others to enable full impacts analysis to lower risk and make sure that there are no surprises while delivering a project/initiative/program.” (Lambert, 2016)

Daniel Lambert, January 26, 2016 http://www.batimes.com/articles/combining-agile-methodologies-and-business-architecture.html

Topic 5 – The Enterprise Security Architecture

Post 1 – Enterprise Security Architecture is more of an ideology than a solution

When we talk about Enterprise Architecture, we do so in the vein that it has been done before, successfully. We can cite multiple frameworks and real world implementations of those frameworks. We can cite various implementations of “in house” architectures that meet the needs of the enterprise within the scope what Enterprise Architecture is supposed to deliver.

When it comes to security, however, that doesn’t seem to be the case. In fact, VMware CEO, Pat Gelsinger is calling for a change to ensure the phrase Enterprise Security Architecture isn’t just an artifact of hope, but something real that organizations can implement and benefit from.

“There is tremendous innovation in the security industry today. What’s needed is an organizing framework — a true architecture that all the leading players can align to so that security can be architected in.” (VMware, Inc., 2016)

(VMware, Inc., 2016) http://www.marketwired.com/press-release/vmware-ceo-outline-need-comprehensive-it-security-architecture-rsa-conference-nyse-vmw-2102581.htm

 Post 2 – A security solution that lives in the real world

I found the idea of Skyport Systems an interesting value proposition. The concept is security hardened hardware that you can take and deploy your insecure systems within, and they become as secure or more secure as if you would have re-written or re-designed them with security in mind. The ROI is the ability to avoid having to utilize millions in technology spend to bring aging systems up to date or to utilize millions of dollars in various firewall, networking, and other security systems.

They cite quite a few use cases. I find the idea interesting because quite frankly most organizations probably consider the risk of breach against the cost of updating their security. And as we see in the news, most of the time the path chosen is obvious. Skyport Systems seems to provide a solution for the interim.

https://www.skyportsystems.net/

https://vimeo.com/150958409

 Post 3 – How to run your business is not the same as how to protect it

When looking for information about this topic, I noticed in the news a lot of discussion about Vodafone creating a new division to offer cyber security consulting services to other organizations. I thought of two things right off the bat. 1. It’s 2016 and companies still can’t get security right, which means it’s either a really hard problem (complex or requires a hard to acquire subset of knowledge) or a really expensive one. But that leads to 2. Consultants don’t seem to ever materially change a business or its processes.

In my experience the concept of hiring a consultant usually goes like this. 1. Invite consultant in (due to perhaps an audit or a concern a board member or executive has had). 2. Consultant is provided limited (or in some rare cases full) view of the organizations’ processes. 3. Consultant provides recommendations. 4. The organization cherry picks the recommendations that best align with their existing processes and strategy.

The very processes and strategies that put them here in the first place.

I think business strategy, process improvement, value chain improvement, and other core business concepts are ripe with opportunity for consultants to add value. A consultant comes in, speaks the language of the business, and improvements can be made.

Security, on the other hand, is a completely different topic. I’m not sure a consultant can lead an organization to start making sound security decisions, or more importantly, materially change their enterprise security architecture in a meaningfully positive way that actually protects their business.

Topic 4 – The Enterprise Technology Infrastructure Architecture

Post 1 – We don’t need a leader, we need the right leader

“A weak linkage to the business creates a void that limits the quality of the resulting IT architecture and the organization’s ability to enforce and sustain the benefits of implementation over time.” (Buckow et. al, 2010)

I think we as studying enterprise architects know this all too well. The article sites “complexity and lack of leadership” as the main driver for the issue, and I couldn’t agree more. When I started this degree, I thought of myself as studying to be an architect, but as I continue to learn more these topics, it seems like leadership underpins the success stories, not any special architecture or technical acumen.

Leading business and IT simultaneously to the same goal is easy to type and read, but seems extremely hard in practice.

(Buckow et. al, 2010) http://www.mckinsey.com/business-functions/business-technology/our-insights/why-business-needs-should-shape-it-architecture

Post 2 – Make like a tree and leaf

“Network overlays such as VXLAN [utilizing the leaf-spine architecture] are common in highly virtualized, multi-tenant environments such as those found at Infrastructure as a Service providers.” (Ethan Banks,2013)

The reason they’re common is because the traditional “tree” architecture for network topology isn’t conducive to everything connected to everything else. When I&O wants to offer centralized services the concept of the network framework has to be the basis of the discussion or it just won’t scale. Granted the network doesn’t sound like an area that can improve business value right up until network latency starts to lose you customers.

(Ethan Banks,2013) http://searchdatacenter.techtarget.com/feature/Data-center-network-design-moves-from-tree-to-leaf

Post 3 – Software Driven Infrastructure

“If you have a database of all of the components that is real time and up to date and accurate, you can recovery from system failures more quickly, not only when there are problems with virtual services but also when there are faulty components in the physical infrastructure.” (Yossi Ben Harosh, 2015)

It’s easy to think about pinging servers or setting up monitoring software on single (static) applications or even on physical servers. What happens when everything is virtualized, IP’s are static and the location you received status from one day is different the next?

While applications utilize more of the abstraction technologies of the datacenter, the support for those items has to change along with it. I think it’s easy to get wrapped up in the “what can we do with this new stuff” idea and not stop to think how it’s going to be supported.

(Yossi Ben Harosh, 2015) http://www.datacenterknowledge.com/archives/2015/12/16/ten-data-center-trends-to-watch-in-2016/

Topic 3 – The Enterprise Data Architecture

Post 1 – It’s not me…it’s your inputs.

“Data architecture should be defined in the planning phase of a new software application”

I think the concept of planning the data architecture for a specific software application is what holds some organizations back from true strategic agility. I realize this may go against fundamental concepts of developing data driven software, but I think even today we’re seeing a slower shift that we ought to be seeing. Big data presents a big problem for current software application methodologies. One day you have data that looks one way and the next you have a completely new set your application wasn’t designed for. That’s like trying to fit an ocean through your bathtub’s drain. It’s not going to happen.

I think we’ll start to see software tools and companies emerge to fill the much needed role of data abstraction layer. I’m not talking about merely making software SQL query agnostic, I’m talking about building an application once that works with any data set you come across. The IBM Watson Explorer is such as system. The idea that your application does something with inputs today makes people immediately think they need to design the application around the inputs. But I think that’s short sighted and we’re seeing the lack of progress in big data technologies as a result. The applications just can’t keep up…yet.

 Post 2 – Data architecture is a waste of time

What’s the point of a data architecture? How you store the data isn’t a value creator in itself. The usefulness is how you analyze the data and what you do with that data. Some data architects want to organize the world’s data. According to internet live stats, there are 7,110 tweets and 2,466,121 emails sent EVERY SECOND and there were 968,882,453 websites created in 2014 alone.

So who’s organizing all of this? I’m not.

No one is, it’s a silly premise. If you’re still spending time trying to architect the perfect data structure for your piles of data, you’re wasting your time. Your time should be spend in technologies that are data structure agnostic. Analyzing structured data is an ancient technology at this point. Data is only going to get bigger and it’s not going to be any more structured than it is today (not very).

Companies aren’t making money based on how slick their data architecture is; they’re making money by creating value from the analysis of every piece of data they can get their hands on. To assume that data is going to fit neatly together in some easily query-able and/or structured way is a naïve thought that will prevent you from gaining a huge strategic advantage that will inevitably be as common as the balance sheet.

Internet live stats, http://www.internetlivestats.com

Post 3 – Don’t focus on only one type of data

The most important data in your organization has something it is hiding. Companies that have figured out how to uncover this mystery have also found ways to turn profit on something that was otherwise ignored. What your data is hiding is something called metadata. And it’s very profitable.

Some have heard that regarding websites or phone apps, if you’re not paying for it (if it’s free) then YOU ARE the product. Meaning, when you’re playing your game or reading an article, you’re being presented with ads. Those ads sometimes seem very personal. You see an ad for a feminine product, and you’re a woman or you see an ad for a type of product you were searching for yesterday. This all happens because of metadata.

Advertisers have figured out the importance of this data within data, but I think there’s a whole world of this metadata that is completely untapped. Predictive analytics sounds fancy, but really all it means is making educated guessing using metadata.

So when you’re considering data architecture best practices, you might want to consider going deeper than the first layer of data that is part of the requirement. Don’t forget about the metadata, because it could become more important than the data itsef.

Topic 2 – The Enterprise Application Architecture

Post 1 – The future of application architecture is to revisit the past.

I don’t have a specific article to point to regarding this topic, but spend 5 minutes researching new application trends and architectures and you’ll be inundated with topics like the cloud, docker, machine learning, microservices, and the list goes on an on.

All of these concepts are tangentially the same thing. They’re enhancements to a digitized manual business process. I think people tend to forget where they came from, so to speak. That neat application you’re making is most likely a fancy digitized version of a manual process. Don’t get me wrong, there are services that just can’t be done manually in the span of an average human life. However, the concept of what we’re doing with applications if fundamentally the same. We’re digitizing the business process. And now we’re spending all this time enhancing the previous digitized versions to make a more efficient digitized version. Knock knock, it’s the law of diminishing returns!

Has anyone actually thought to stop and look around? Is the cloud going to make you more money? Perhaps it reduces development time and allows you to ship code faster or load balance more efficiently to take on more visitors during a surge. So perhaps it can make you more money. But are those “easy wins” compared to significant gains?

If you did stop and look around, I think you’d find a shift in comparison to the yesteryear of how businesses are run. 50 years ago the accountants ruled the world of business. A new idea came about and the accountants determined if the numbers worked. Marketing, sales, everyone went through accounting. That made business sense.

Now everything goes through technology in some way, much like they used to do with accounting. However, rather than focusing on the business side, they’re focused on discussions of technical feasibility or whether or not something will show a single digit improvement in speed. Business opportunities are measured in terms of “can we do this with our existing technology or do we have to upgrade?” Why didn’t you stop to think about potential business ventures BEFORE you built your stack? Or why are you waiting till now to evaluate a business venture that you’re probably too late for anyway.

I think the future of application architecture is a much more dynamic set of rules for how applications are built. Building for today is easy. Heck, building for tomorrow is not that hard either. But building for next month, regardless of what happens, is the future. If you can figure a way to do that, you can write your own check.

Topic 2 – Agile for the business

The concept of agile development isn’t new, but the adoption hasn’t permeated every corner of the business world either. Agile development makes a lot of sense to people that have experience with it. You provide iterative changes to a product or service along with the consumer who provides feedback along the entire process. This makes it nearly impossible to ship something the customer or consumer didn’t want.

What if we took this iterative feedback loop and adopted it toward the business itself? Instead of the business coming up with iterative changes to their existing business processes, the iterative changes were to the business strategy. What if one day you were working on an application that did A, but the business was interested in testing out a completely different method altogether?

That idea is not crazy, it happens all the time in the startup world. Something called the MVP or minimum viable product is built to test a business theory. For example, will people buy shoes online? Before Zappos, no one knew. So Nick Swinmurn got this idea of putting shoes online. Did he pay for an ecomerce website to be built and line up suppliers and customer service representatives and a sales team? What about inventory? Did he have to research which shoes sold the best and stock up? What about sizes? What if people buy his online shoes. Did any of this happen?

Nope. Nick built an MVP. He went to a local shoe store and asked if he could take pictures of the shoes in the store, which he would then post online. If a shoe sold, Nick would buy the shoe from the store at full price and ship the shoe to the customer.

Nick simultaneously built a business before it was even a vetted concept. What if the same happened within an existing company? One morning the business partners approach IT and tell them they’d like to build an MVP. In fact, they’d like to start building lots of MVP’s. Some will work out some will fail and die. Once everyone stopped laughing, it might interesting to talk it through.

I think the idea would be to start trying MVPs with the existing architecture and application stack. But the ultimate future would be to provide a playground of business opportunities where a business person’s dreams are built in small chucks to test out and vetted for true business opportunity.

In today’s world, most application architects would laugh you out of the room citing the impossibility of building such a platform. But everything’s impossible until it happens.

Topic 3 – Applying the concept of SOA to Data

The sort of thinking that led to flexibly integrated SOA solutions should now be applied to data.  Get rid of that single schema, concentrate on having data served up in a way that matches the requirements of the business domains and concentrate governance on where its required to give global consistency and drive business collaboration. (Jones, 2013)

I really like thinking about using big data to drive business decisions and strategies automatically. Who would ever thought that the stock exchange trading floor would be completely replaced by algorithms? Imagine what a “typically business” is going to look like in 20 years. Will we recognize it? It think many spend a lot of time trying to refine today’s processes. The real steps forward are made in paradigm shifts. Thinking of how to use SOA to improve your current process is a step backward. Using SOA to enhance a fully automated big data driven solution is what will drive far future strategic advantages.

Steve Jones, 2013. http://www.zdnet.com/article/time-for-service-oriented-thinking-in-the-big-data-space/

 

Topic 1 – Stack overview

Post 1 – Are these all REALLY created equal?

874_t1_elements

Figure 1: The Traditional Elements of Enterprise Architecture – PSU World Campus

According to Cameron (2009), “while these areas are the traditional breakdowns for analysis, they imply that business understanding is approximately one quarter (or less) of the process or one quarter of the importance.”

The problem with images/info-graphics like the above is people tend to make inferences and conclusions that the creator might not have intended. Someone might look at this image and rightfully think the 4 elements of enterprise architecture are all equally important or they somehow all garner equal influence or all contribute to the whole equally.

What I’d really like to see is a more realistic depiction of the elements. I would make it look more like this…

Business Architecture

Data Architecture

Application Architecture

Technology Architecture

I truly believe the stack should start with the business architecture. Without the business the rest of the layers are useless. From that point there are probably valid arguments for which layer comes next, but for my point of view it’s data. The only reason data isn’t first is because by itself it doesn’t do anything, but it’s a very close second. Followed by application and lastly technology. Not only does the above show an order but the large to small font should also indicate relative importance.

Cameron, B. 2009. The IST Enterprise Architecture Perspective

 

Post 2 – Outsourcing the Stack

“In previous generations, large technology vendors fought fierce commercial infantry wars to occupy an enterprise’s technology stack….These were expensive battles, and only a few large technology companies, such as Microsoft, HP, Oracle and IBM, had the resources to compete….Once exclusively the province of just a few large well-capitalized technology infrastructure companies, new competitors are emerging from all corners of the enterprise infrastructure industry.” Savitz, (2013)

A flood of emotions and ideas come to my mind when I think about outsourcing and even more so when I think about outsourcing something as large or important as the technology stack. If you take away my infrastructure, who’s going to look after my best interests? Will I lose control of by business if I don’t retain full control? Think of the risks!

Then I come back to reality. The truth of the matter is doing “everything” means you probably don’t do it all well. No one has an infinite budget with an endless line of superstar performers to keep every aspect of the business in tip top shape. More likely the company has stellar performance in whatever its core competency is and good, lackluster, or often barely scraping by within the other areas that support the core competency.

As platform as a service and software as a service become more prolific in the business world, I think there will be a major shift in the overall acceptance (for lack of a better word) of letting parts of your business go to be run by (dare I say) more competent hands. Business are run by large egos that think they can do it all. But it takes an even bigger person to realize their weaknesses and identify ways to strengthen them. Even if that means asking someone else (or another company) for help.

Savitz, 2013. 5 Opportunities In Enterprise Infrastructure For 2013

 

Post 3 – Don’t look at us, the technology is flawless.

7. Thinking Enterprise Architecture Equals Technology Architecture … Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don’t align your IT investments with business goals and won’t power your business with technology innovation.“Kabai (2013)

Leading an Enterprise Architecture initiative with a Technology Architecture seems obvious to some. They look at current state and reason the architecture could be improved (or was poorly designed) and therefore it needs a makeover. It’s also, in my opinion, low hanging fruit from an enterprise strategy perspective. Improving a company’s architecture is much easier for technologists to digest and grasp than improving a company’s business strategy and providing sound technological recommendations that support that strategy. That kind of discussion takes expertise on both sides of the fence. If the technologists are the only ones that participate or show the most interest, it will be a very one sided effort destine for failure.

One lesson in particular I learned early on was how marketing can help an Enterprise Architect. When you understand why that is, it’s easy to understand why leading with technology is a moot effort.

Kabai, 2013. 8 Reasons Enterprise Architecture Programs Fail