Blog #7 - Emerging Technologies, Innovations & Trends

Digital Transformation = Digital Marketing = EA 

I have heard the term Digital Transformation thrown around at a few different conferences and struggled to understand the term in whole. The first time I heard the term I thought maybe it was someone being cute trying to rename EA to make it sound sexier.

Here are a couple definitions of Digital Transformation:

1. ("Digital transformation: online", n.a) says, Digital transformation is the profound and accelerating transformation of business activities, processes, competencies and models to fully leverage the changes and opportunities of digital technologies and their impact across society in a strategic and prioritized way. 
2. (Wikipeda, n.a.) says, Digital Transformation is the change associated with the application of digital technology in all aspects of human society. 
3. (Westerman, Bonnet & McAgee, 2014) say, Digital transformation is the use of technology to radically improve performance or reach of enterprises. 

As you can see these three definitions are about as different as the definitions of EA that we all see. When comparing it to Digital Marketing, I think there is a clear difference. (Stender, 2015) shows that Digital Marketing is seen as the umbrella term for the marking of products or services using digital technologies to reach and convert leads into customers. So with that we can see the two are clearly different.

Looking at Digital Transformation and EA, (Stender, 2015) focus on the "data" aspect of digital and goes on to say "digital is about the creation of data from hardware and software; digital is about the intelligent transportation of data; and digital is about the use of data to power smart industries." With that definition is seems that Digital Transformation would be more an aspect of EA then a competing factor.

References
Digital transformation: online guide to digital business transformation, (n.a.). Retrieved December 4, 2016 from http://www.i-scoop.eu/digital-transformation/

Digital transformation (n.a.). Retrieved December 4, 2016 from https://en.wikipedia.org/wiki/Digital_transformation

Westerman, George., Bonnet, Didier. & McAfee, Andrew. (2014). The Nine Elements of Digital Transformation. Retrieved December 4, 2016 from http://sloanreview.mit.edu/article/the-nine-elements-of-digital-transformation/

Stender, Morten. (2015). Digital Transformation - is it any different from EA or Digital Marketing. Retrieved December 4, 2016 from https://www.linkedin.com/pulse/digital-transformation-any-different-from-ea-morten-stender?redirectFromSplash=true

Sketching A Roadmap for Enterprise Architecture
I found this webinar by (Evans, 2016) to be very interesting in helping understand EA and how digital disruption affects it. The webinar helps understand the different aspects of digital disruption and how it changes the business model it is working with. He talks about how digital disruption occurs as the business model level.



Another key point was the different life-cycles we need to be aware of. The touches on the idea that business models have cycles and he states that is key because business models are not always thought of as having a life-cycle.



Evans also talks about how digital is an important aspect because it accelerates the rate of disruption. He also talks about how digital shifts the control to the consumer this demands the enterprise to change. Digital is also more about social and big data.

 

Evans also talks about how the architect will be important in digital disruption because they have a deep understanding of business capabilities and technology. He also touches on how a new architect job family is starting to develop.



Here are some takeaways from the article about the webinar itself.

1. Business models do not last as long as they used to – and digitization accelerates disruption and rapidly shortens the cycle; 
2. Every CEO in every organisation must come to terms with digitization and its effects, such as how: 
3. it will affect their industry and competitive position; 
4. their own organisation can leverage digital capabilities. 
5. Understanding existing and required business capabilities (people, process, technology and information flows) is extremely useful when contemplating candidate business models – if not flat-out necessary; 
6. A new architecture job family is emerging to support disruptive strategy and business model innovation; 
7. The emerging job family is taking EA from ‘EA = Business Architecture + Enterprise-wide IT Architecture (EWITA)’ to ‘EA = Business Design’; 
8. This new approach to enterprise planning, which unifies business architecture and the traditional world of EA, also recognises the importance of value discipline alignment for business model and capability orientation; 
9. Organisations (and architects) must now think about Enterprise Lifecycles and seek to harmonise and synchronise the commissioning and decommissioning of business capabilities to bring new products to market, manage the business model portfolio and support the continual development of the brand platform – and the broader enterprise as a going concern. 

References
Evans, Hugh. (2013). Webinar: Sketching a Roadmap for EA in the Age of Digital Disruption. Retrieved on December 4, 2016 from http://enterprisearchitects.com/webinar-sketching-a-roadmap-for-ea-in-the-age-of-digital-disruption/

Innovation

Innovation seems like an easy thing and I feel like most people think they are being innovated when however they are just doing the same things in a slightly different manner. I didn't have a single article for this, instead I decided to compile a few sites and thoughts that can help us be more innovative.

One thought to be more innovative is to get into the mind of someone that is being innovative. Here is a like to a sight that called out the top 25 most influential innovation blogs and experts to follow in 2015.

http://www.improvides.com/2014/12/21/top-25-innovation-blogs-experts-2014-winners/

Here are some tips for improving your innovation:

1. Shapiro (2012) 
1. The brain wants pains solved first. Be the aspirin. 
2. Expertise is the enemy of innovation. Keep looking, don’t stop with the obvious answers. 
3. The brain wants solutions, not problems. Ask better questions. 
4. The brain craves commonality. Work with people who are not like you. 
5. The brain sees what it believes. Get someone to play devil's advocate. 
6. Your brain only sees a fraction of reality. Purposefully retrain the brain. 
7. The brain thinks to much. Quiet the judgmental part of your brain through meditation, yoga, showering or any other relaxing activity. 
2. Acton (2015) 
1. Turn "Can't" Into "Can If". Next time instead of saying "We can't because…" try "We can if…" instead. 
2. Access Your Assets. Think about more than just the assets you own, what about the ones you have access to. 
3. Ask Impossible Questions. Impossible questions turbocharges creativity and catapults us into problem solving mode instantly. 
4. Put Constraints on Yourself. Task can easily slide if you don't put constraints on them. Limit time, money or resources to help drive things. 
3. Su (2011) 
1. Persistence. It takes hard work and determine to bring something to life. 
2. Remove Self-Limiting Inhibitions. Be open to new ideas and solutions without setting limits. 
3. Take Risks, Make Mistakes. Don't be afraid to fail, learn from your mistakes. 
4. Escape. Relax and you will find some of your best ideas. 
5. Writing Things Down. 
6. Find Patterns & Create Combinations. Ideas come from other ideas. 
7. Curiosity. Practice seeing things differently. 

I thought think exercise of looking at different sites in a quick manner would be more of a check the box they of exercise. However it really got me thinking of how I can be more innovative or at least position myself for the opportunity. I also learned that you don't need to review something with a fine-toothed comb to get value out of it.

References
Shapiro, Stephen. (2012). 7 Ways to Outsmart Your Brain to Be More Innovation. Retrieved December 4th, 2016 from https://www.americanexpress.com/us/small-business/openforum/articles/7-ways-to-outsmart-your-brains-wiringand-become-more-innovative/

Acton, Annabel. (2015). 4 Incredibly Simple Ways to Become More Innovative. Retrieved December 5th, 2016 from http://www.inc.com/the-muse/4-simple-ways-to-become-more-innovative.html?cid=readmore

Su, Tina. (2011). 7 Habits of Highly Innovative People. Retrieved December 5th, 2016 from http://thinksimplenow.com/creativity/7-habits-of-highly-innovative-people/

Blog #6 - Business Architecture

Business Context

We have heard plenty about aligning business strategy and IT execution as a core of Enterprise Architecture. While this is important we have also heard about making sure to look at business context as part of it. According to Malik (2016), "A business analyst may start with some bit of strategy and start hunting for capabilities… a business architect will start with a model of the enterprise, its value streams and its business models. Starting with strategy is a fool’s errand." He continues to describe why starting with business strategy is not a good approach and states that the "business model comes first, and the strategy comes second."

This article takes a direct stand that business context and business model are the most important part of business architecture. For me this is something I need to get a better handle on and define more completely. I think most folks have a good understanding of what their business does and has some idea of the context that the business operates under. To be successful in an EA practice it is important to get the full view and understand the big picture around the business model and context.

I like the graphic included in Malik (2016) showing how the business strategy helps move from today's business model to tomorrows business model. This helps to understand that the business model needs to continue to be reviewed and then align the business strategy to accomplish the goals of the business model.

Reference

Maklik, Nick (2013). Business Architects: Do Not Start With Strategy. Retrieved November 5th, 2016 from https://blogs.msdn.microsoft.com/nickmalik/2013/08/24/business-architects-do-not-start-with-strategy/

Don't Boil the Ocean

How many times have we hear the phrase "don't boil the ocean" when it comes to EA. The same holds true for business architecture. Fenster (2016) reaffirms that statement and goes on to say, "The business case for a central architecture team is a difficult one to write and to get approved in a changing world." He goes on to say that "Embedding architecting skills within individuals, who then operate in different roles across the organisation, rather than training specialists and placing them in vunerable teams is growing as the alternative way forward."

This is driving to the idea of agile architecture. I like the idea of agile architecture, it provides a way to get value from EA without having to define an execution plan for a full blown EA practice. With organizations that have a diverse portfolio or a large strategic footprint that needs to be accounted for using an agile approach to architecture seem like the only way to show the incremental benefits of EA.

For my organization this seems like the only way to make progress on an EA front and to continue to understand and show value. By addressing problem area in regards to business context and strategy in bit size pieces it becomes each to show the value in EA. Also with give the challenge of time allocated to running the business any time that can be spent architecting will add significant value even if in incremental stages.

One question I would have for the group would be, does anyone have experience using an agile architecture approach?

Reference

Fenster (2016). Business Architecture " Don't boil the Ocean". Retrieved November 5th, 2016 from http://businessarchitectsblog.blogspot.com/2016/09/business-architecture-dont-boil-ocean.html

Business Architecture

I found the article from Bergsman (2013) interesting. He provides a couple tips to getting business architecture off the ground. He touches on a couple things that we have heard many times before in EA. One is orienting EA around the business and not technology and another is using the business as the foundation of EA. These things are not new but I thought the graphic he provides has some additional subtle annotations that I haven't seen before. The recommendations with the green checkmarks and the things to avoid with the red x's.

In addition to the graphic I like his definitions of the two types of business architectures. Below are his two definitions from his article.

1. Business Model Architecture—Captures the business model as it changes with business strategy. This type of architecture identifies and maps changes to supplier relationships, channel management, customer relationships, and other strategic-level organizational areas. It may also be known as business drivers in some organizations. 
2. Business Operations Architecture—Captures the operating capabilities necessary to enable business strategy. This type of architecture identifies and maps changes to the business capabilities required for the organization to operate and adapt to changes in strategic direction. 

These two types of business architecture will be help and important to remember as we build our EA practice.

Reference

Bergsman, Jeremy. (2013). Tips for Getting Business Architecture Off the Ground. Retrieved November 6th, 2016 from https://www.cebglobal.com/blogs/tips-for-getting-business-architecture-off-the-ground-3/

Blog #5 - Security Architecture

Security architecture needs to be part of EA

Campbell (2015) outlines a scenario that I think more organizations are faced with, yet take somewhat for granted. We routinely setup systems with a production, test and development environment and most of the time our test environment nearly mirrors our production environment for load testing, disaster recovery testing and because we want things to match. Below is an excerpt from one of the Western Australia's Office for the Auditor General's report.



We are in the same boat as the statement above when it comes to maintain the same strict controls across all environments. We have outlined this as a security risk and we have started to address it. When it comes to our financial and HR systems we mask any personal identifiable information. We try to maintain a subset of information in those non-production systems if possible. We are now requiring individual access requests for those environment and requiring approval of those requests from system owner.

We certainly have a long way to go to do this across to board. However, I think we have identified a risk and are working to mitigate it.

Campbell (2015) goes on to state, "A security architect will understand the complicated tensions between the business, policy, cost and delivery, and ensures the security of systems being delivered are never compromised for the sake of making delivery easier or getting into production quicker." It is important to have someone reviewing security from the beginning of a system installation to make sure it can or will adhere to the policies at hand. We try to have most application reviewed from a SOX perspective even if they are not a SOX application because at any point they could become one. This allows us to make sure we have things like separation of duties, user access reviews and sensitive data reviews.

In all it is going to important to start including Security architecture in the overall Enterprise Architecture practice.

Reference
Campbell, Tony (2015). Why you need to build security architecture into your enterprise. Retrieved October 20th, 2016 from http://www.itnews.com.au/blogentry/why-you-need-to-build-security-architecture-into-your-enterprise-411592

Adaptive Security Architecture

I found an interesting post that touched on a bit more detail around adaptive security architecture and gave a couple area to focus on. Amrutha (2016) provides two blog post touching on adaptive security architecture. In the first Amrutha (2016) states "The adaptive security architecture can help enterprises shift their existing mind-set of “incident response,” wherein incidents are thought of as occasional, one-off events, to a mind-set of continuous response, where they assume that cyber-attacks are relentless and hackers have the ability to continuously penetrate the systems." This is an interesting statement and I think makes you open your eyes a bit if you are not directly involved with security practices.

Amrutha (2016) goes on to quote the Gartner report, "Designing an Adaptive Security Architecture for Protection from Advanced Attacks," which outlines four, high-level categories of competence.

1. “Preventive” capabilities are the preventive policies, products, and processes that are put in place to counter attacks. The key goal of this category is to raise the bar for attackers by reducing the surface area for attacks before these attacks can affect the entire enterprise. 
2. “Detective” capabilities are designed to discover attacks that evade the preventive category. The key goal behind this category is to reduce the dwell time for threat detection and therefore prevent potential damages from becoming actual damages. 
3. “Retrospective” capabilities are required to drill down and remediate issues discovered by detective activities (or by outside security services) and to provide forensic insights and root cause analysis. Retrospective proficiencies can be used to recommend new preventive measures to avoid future incidents. 
4. “Predictive” capabilities enable the security team to learn about and record external events via external monitoring of the hacker activities to proactively anticipate new attack types against the current systems. This intelligence is later used as feedback into the preventive and detective capabilities, thus closing the loop on the entire set of adaptive security capabilities. 

In Amrutha's (2016) second blog post about Adaptive Security Architecture he starts to talk about four reasons why organizations should adopt an Adaptive Security Architecture. Those are:

Most organization today continue to invest mainly in prevention-only security techniques.
The advanced security capabilities from different vendors are not integrated appropriately.
Traditional monitoring practices are becoming increasingly insufficient.
Most organizations have many blind spots while implementing incident response techniques.

Amrutha (2016) talks about moving away from prevention-only techniques and making sure you start to focus on detection, response and prediction capabilities. I know we have started to move way from just prevention. It seems like as soon as you can come to terms with the idea, "that you will never keep hackers out," the sooner you can move on to the next three areas.

He also talks about context-aware security, this is an interesting area that I want to follow up with our security group on. It seems like it could help increase the likely hood of preventing unauthorized access.

He continues to talk about increased levels of monitoring across all layers of the IT stack. This is sometimes difficult given vendor solutions. Not all vendors have build in or are concerned about monitoring their own environments as we would like them to be. We tend to just shake our heads and move on but from what Amrutha (2016) is talking about we need to start focusing on it more.

Overall, I need to get a better understanding of our currently security procedures and how we are implementing the four high-level categories of competence.

References
Aprameya, Amrutha (2016). Enhacing IT security with adaptive security architecture - part 1. Retrieved October 20th, 2016 from https://blogs.manageengine.com/it-security/2016/04/07/enhancing-it-security-with-adaptive-security-architecture-part-1.html
Aprameya, Amrutha (2016). Enhacing IT security with adaptive security architecture - part 2. Retrieved October 20th, 2016 from https://blogs.manageengine.com/it-security/2016/04/14/enhancing-it-security-with-adaptive-security-architecture-part-2.html

Risk Based Security Analysis

I was looking for more information on risk based security analysis and ran across the Crowther (2015) article. It was interesting because it established a base for risk and security. Crowther (2015) uses references to define risk as:

• Risk is the study of future bad events. 
• Risk is the study of future events that have uncertainty or unknown/ambiguous precursors or consequences. 
• Risk is the study of how bad the consequences of the bad events could get. 

He goes on to define security as:

• Security is concerned with preserving the value of an asset (or operation). 
• Security is concerned with threats that might undermine the asset value. 
• Security is concerned with the actions and responsibilities of a protector. 

What I liked about the article is that Crowther (2015) states the obvious, that it is difficult to model the future of unknown events and put a value or impact on future events without a past reference. The "zero-day" vulnerabilities are called just that for a reason. It doesn't seem like you can predict a "zero-day" breach, you can hope to react to it in an efficient manner.

Crowther (2015) goes on to talk about some false presumptions about risk management and security analysis. They are as follows:

• Risk analysis won’t make countermeasure recommendations. 
• There is not “a single, accepted risk assessment methodology. 
• Traditional risk analysis cannot help you identify unimagined, emergent threats and hazards. 
• Risk analysis does not lend itself to naive data science. 

If you have time it is worth reading his explanations of each. His explanations show how hard it is to be on the leading edge of risk management and security analysis. It is a balance of making a gut decision based on outdated information and putting in the correct measures to lessen the impact of a security event.

Reference
Crowther, Dr. Kenneth G. (2015). Do you want risk-based security analysis or security risk analysis? Retrieved October 21, 2016 from http://www.innovativedecisions.com/blog/2015/9/25/do-you-want-risk-based-security-analysis-or-security-risk-analysis

Topic #4 - Infrastructure Architecture

Does Cloud Spell the Death of Infrastructure Architecture?

Selby (2016) explores the idea how the role of the infrastructure architect has changed or will exist with the move towards the cloud. The debate is short lived on whether or not the role is dead but he certainly points out that is will/has changed. I would agree with his point the concept of infrastructure is changing however for us it is slowly changing. We have a significant investment in our data center and will continue to have that investment. One of the major hurdles we have with moving towards the cloud is that our data center is considered and asset since we own the equipment in the data center. The idea of cloud challenges our capitalization policy that we currently have in place for IT assets. That is one area that is a heated discussion when it is brought up. However, that aside I think there is a real need to figure out the right balance of cloud vs on premise infrastructure that is needed to fulfill business needs. Selby (2016) starts to touch on this with the following statement, "the Infrastructure Architect is already fast becoming the Integration Architect (IA) - a specialist in tying together services the business requires from the physical connectivity right up to the presentation layer and application delivery - and doing so on the most appropriate platform, be it in-house or with an array of cloud providers." I would certainly agree with that sediment. I think as architects we need to figure out the right blend of infrastructure it going to be key. Like Selby (2016) says, the business demands, "consumer IT ‘just works’ and seamlessly integrates, so why can’t my corporate application." It seems that this is where the role of infrastructure architecture is headed, however for us it will be a while before we get all the way there because we will still need to focus on our on premise infrastructure as well.

Reference
Selby, Rob (2016). Does Cloud Spell the Death of Infrastructure Architecture. Retrieved October 5th, 2016 from http://www.adapt.com/whats-new/blog/does-cloud-mean-the-death-of-infrastructure-architecture.html

Data center infrastructure architecture redrawn to meet new IT demands

In December of 2013, Courtemanche and Boisvert (2014) interviewed Henrique Cecci research director at Gartner Inc. about cloud and data centers at the Gartner Data Center Conference. Cecci mentions that application deployment is driving the need for new approaches to infrastructure. He also mentions the need to be able to deploy infrastructure faster than ever before in order to keep up with the application demands.

For my organization we made a significant investment in virtualization several years ago and now are reaping the benefits of that decision. There are a couple different aspects that virtualization has allowed us to excel in. The first is provisioning, we can provision a set of servers to support a new deployment in the matter of days (maybe hours) if needed. We do not need to wait on procurement of hardware to enable these new applications. Second is disaster recovery, we have been able to establish a disaster recovery strategy with complete failover to a secondary data center. I suppose maybe even a 3rd benefit is our backup strategy, we are able to take snapshots of servers prior to upgrades and revert back to the original if an upgrade goes south.

I also find the part of the Courtemanche and Boisvert (2014) interview where Cecci talks about modernizing the data center to meet demands. For me, I always looked at hardware refreshes as a way to get the most modern processing and storage power available. I hadn't thought about the efficiencies that are gained along with that. Total cost of ownership analysis like this, "If you are reducing the temperature in the data center by 1 degree Celcius, that may represent 4% energy costs in the data center", are something that doesn't seem like much on the surface but apply that thinking to infrastructure architecture as a whole and there might be more cost justification in something like a hardware refresh.

Reference
Courtemanche, Meredith and Boisvert, Michelle (2014). Data center infrastructure architecture redrawn to meet new IT demands. Retrieved October 5th, 2016 from http://searchitoperations.techtarget.com/feature/Data-center-infrastructure-architecture-redrawn-to-meet-new-IT-demands

Scaling Microservices Architectures in the Cloud

I found the article from Saini (2015) a nice short review of architecture when looking at micro services. This has been something I have been thinking about for the last few months and how we might leverage this idea of micro services. To gain the full advantage of micro services you want to be able to scale your architecture to process additional load as needed. As Saini (2015) points out you cannot accomplish this with the traditional work horse server instead you need to be able to use a multi-cluster setup. For me this is a challenge and the biggest part of it is around licensing. When I look at our licensing around our middleware servers they are core based and that becomes a problem if/when you want to scale rapidly. This is a challenge I'm trying to get my head around when it comes to hosting micro services. We are also currently mixing some batch processing, services and messaging. These three integration patterns have different infrastructure requirements, this is another area I'm evaluating to see better understand what we can/should do from an infrastructure perspective.

Reference
Saini, Atul (2015), Scaling Microservices Architectures in the Cloud. Retrieved October 9th, 2016 from https://www.fiorano.com/blog/infrastructure-architecture/

Topic #3 - Information Architecture

The State of Information Architecture

In Walker (2015), he surveys a group of around 40 enterprises from all different industries, sizes, maturity levels and geographies about the state of their information architecture. The results are interesting and even spot on in terms of my organization.

The first question deals with the level of impact Enterprise Information Architecture (EIA) has delivering business driven outcomes. The chart below from the article shows that while 90% think it is "ideal" or "significant".



I would agree that we have this same kind of thought in our organization. However, I think we also have trouble understanding the impact that good information architecture would have on our organization. We have completed assessment from Gartner & Hackett and both a reviled that we need to have better data management.

The second question asked about the current state of the enterprises' EIA practice. In the article, it states that "only 16% felt that EIA as a practice had been fully implemented or mostly implemented.



Again I would agree with this from our company prospective. We have not implemented an EIA program. I will be working with our organization to start looking at how we implement an EIA. We have tried to do some governance activities in the past around data management and they have been less than successful. I think if we had a larger of view of EIA then the governance program would be easier to tie directly back to why we are trying to implement such controls.

Walker (2015), goes on to ask what level of impact does EIA have on major efforts like Big Data and traditional MDM and 96% of respondents answered "ideal" or "significant". Again after reviewing other notes around EIA, I also feel that a good EIA program could have significant impact on those efforts. It seems to give everyone a path to walk towards a common goal and highlights the importance of good information management.

The final question was centered on trying to agree on a good definition for EAI. According to the article, "60% of respondents they felt that this definition represented enterprise information architecture:

Information Architecture is an aspect of enterprise architecture that enables an information strategy or business solution through the definition of the company’s business information assets, their sources, structure, classification and associations that will prescribe the required application architecture and technical capabilities."

I feel that that is an adequate definition for EIA.

It is clear that EIA is important and we need to be focusing on how to develop EIA in our organizations. Walker (2014), finishes the article with an important summary:

"However what this data does tell us is that while EIA is important (or maybe even critical) we still don’t have:

• A collection of proven practices 
• The right structures and framing for the EIA space 
• Proven methods that result in predicable and predictable outcomes 
• A clear organizational and competency structure for EIAs" 

Reference
Walker, Mike (2014). The State of Enterprise Information Architecture. Retrieved September 23rd, 2016 from http://blogs.gartner.com/mike-walker/2014/07/23/the-state-of-enterprise-information-architecture/

Data is NOT Information
In the article from Aitken (2015), he attempts to clarify why data is not information. I really like his example of how data without context has no value. The example is this, "take a column of floating point values in a database table – while a developer might be able to discern something about the meaning of the values by physically inspecting the database table and column names – the values are meaningless to the naive user until they are presented on a computer’s screen in a field labelled 'Cholesterol level (mg/dL):'"

I believe we have the issue that data loses its context shortly after it leaves the source system. While the data may be extracted with column names like indicated above it doesn’t take much for someone to manipulate those column names and give the data new meaning in a new context. We have a classic example with the "number of customers" question. Being a utility company, I would say the number of customers would be the number of service points that we currently maintain. Those service points might be active or inactive so not all service points would be related to an active customer. Another point of confusion is that if you don't spell out that one customer can be responsible for multiple service points you can end up with too many or too few customers. So for this example the context should be "customers as number of service points", however many times the number gets labeled just as customer losing the full context of the data.

I like the idea of information asset as spelled out by Aitken (2015). He states that like other assets information assets have value and a life-cycle. I think it is important to label the value of information in terms of data otherwise we end up just storing everything because "storage is cheap." The idea that information has a life-cycle is an interesting concept and I would like to explore that further in our organization. I think the idea certainly is valid as we have data like customer that expires after a certain period in time. Once we have a customer they might not always be a customer so at some point that information would expire.

I'm going to be spending time with my team to help build up the idea of EIA and how we improve our understanding of information within our enterprise.

Reference
Aitken, Chris (2015). Data is NOT Information. Retrieved September 23rd, 2016 from http://enterprisearchitects.com/data-is-not-information/

Why EIA Matters
I have read a couple blog articles from Seth Earley and like the content he provides. In Earley (2013), he talks about getting back to the basics and talks about taxonomy. He continues to talk about two core artifacts needed to improve EIA. Those two artifacts being a good enterprise taxonomy framework and a domain model. After reading a few of his articles on taxonomies those two artifacts started to make more sense.

In our organization we have a good understanding of what we do in various area, however we lack an overall model of what high-level interactions are needed to run the business. I feel we have maybe approach our data governance from a slightly wrong angle. I think we need to address the overall view of the business and build out our enterprise taxonomy and establish a domain model that represents our enterprise. I think doing this will help move our data governance efforts ahead in a way we haven't seen before.

In Earley (2015), Earley tries to reestablish the definition of a taxonomy. I agree with his statement as an IT professional it is way too easy to get into the weeds of the data of an application or system instead of trying to address the higher level abstract perspective needed to build an enterprise taxonomy. This article help me understand how to look at an enterprise taxonomy and how to potentially use it at my organization.

Reference
Earley, Seth (2013), Why Enterprise Information Architecture Matters. Retrieved September 23rd, 2016 from http://www.earley.com/blog/why-enterprise-information-architecture-matters

Earley, Seth (2015), Why Information Taxonomy Must Represent the Landscape of the Business. Retrieved September 25th, 2016 from http://www.earley.com/blog/why-information-taxonomy-must-represent-landscape-business

Topic #2 - Application Architecture

Don't Ignore Application Architecture This is something I have been struggling with after getting introduced to the concept of micro services. When attempting to split out services into smaller more manageable pieces other things become a bit harder to manage, like security. There are certainly tools that can help you manage all of these new service and really to be effective you would need to implement something like an "API Manager" tool to help. As an example if you take a SOAP web service that has 10 methods contain within it and make each one of those 10 methods its own micro service you now have 10 end points to manage security on instead of just one.

This brings me to my first question for the class, has anyone started implementing micros services or have a large service catalog they have to maintain? What tools do you use to help maintain security or even the dictionary of these services?

I have another example were we failed to keep application architecture (maybe slightly technology architecture) in mind. We purchased a large work management software package and when it came down to the final selection between the top two the one that was selected we selected because it was slightly more user friendly. One big over sight that the application ran on AIX hardware which required physical servers. This decision was not fully considered as part of the discussion. The reason it was not the best decision is because nearly all of our servers run in a virtual environment which please heavily into our disaster recovery strategy. Luckily the vendor had a new version of the application to be release prior to our go live date so we decided to delay the project a couple months so we could take advantage of the new Linux based version.

Reference Stangarone, Joe (2013). Application Architecture: Ignore at your own risk. Retrieved September 11th, 2016 from http://www.mrc-productivity.com/blog/2013/03/application-architecture-ignore-at-your-own-risk/

Decoupling your Application Architecture Even though this is a short article I think it still rings true. Garrett (2016) reminds us to "Decouple Everything!".) While this can be difficult sometimes it is certainly something to remember as we are architecting solutions to fit business needs. Garrett (2016) gives us three things to remember:

1. Any integration model that assumes or imposes that one service know about another, or respond synchronously to another is often a sign that you have imposed unnecessary coupling. 
2. Any application interface that directly reflects the architecture or data model of a backend resource will lead to functional dependencies in the future. 
3. Any business event that maps to data that multiple applications or services must leverage, suggests that an event-driven architecture is the best choice. 

We are starting to see benefits from using integration to decouple our applications. We are in the process of implementing a new work and asset management system and we are taking this approach. We are attempting to keep everything asynchronous and make everything we can a service (where it makes sense.) We are attempting to also take event driven integration into consideration from systems like Finance and Budgeting where things have always been very specifically design for the need. I have asked our developers to think about only delivering their data to a middle point and not worry about what the end system needs, again to a degree, you need to know a somethings about the destination. It has been a challenge to change some minds but we are starting to get people to understand how we want to decouple our integrations between systems.

Another question for the class would be, what kind of luck have you had in decouple application architecture and what have your communication methods been?

Reference Garrett, Ross (2016). Decoupling your Application Architecture. Retrieved September 11th, 2016 from https://www.pushtechnology.com/blog/decoupling-application-architecture/

Four-Tier Application Architecture I have been out of application develop realm for a bit. I'm sure I have encountered the Four-Tier Architecture before but I don't recall it off had. Nommensen (2015) expands on article by Forrester Research which splits out the application layers into four distinct layers.



It is an interesting concept and I'm curious if anyone has actually seen or implemented this architecture in an enterprise setting.

We are still using a three-tier architecture for most of our development but I could see where focusing on a client tier could be beneficial. We have decided to focus specifically on responsive design when it comes to our web development. Most of our integration is internally focus and doesn't need to have a major focus on the client tier.

This is certainly some to keep into consideration for future architecting efforts.

Reference Nommensen, Patrick (2015). It's time to Move to a Four-Tier Application Architecture. Retrieved September 11th, 2016 from https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture/

Schadler, Ted (2015). Mobile Needs A Four-Tier Engagement Platform. Retrieved September 11th, 2015 from http://blogs.forrester.com/ted_schadler/13-11-20-mobile_needs_a_four_tier_engagement_platform?utm_source=time-to-move-to-a-four-tier-application-architecture&utm_medium=blog

Topic #1 - Enterprise IT Stack

New Continuous IT Stack

I thought article from Wall (2016) was interesting and very now.  He talks about how the IT stack has changed with the on slot of connected devices and the need to keep up with the changing IT landscape.  Development within the IT stack now is measure in weeks and months instead of months and years.  Organizations must learn how to adapt to the new IT stack leverage continuous development and the stressed the need for DevOps. 

DevOps is relatively new to me and is an interesting concept and especially challenging in a very lean organization.  It almost leads me to think there might be a sudo layer not included in EA that has to do with the "people layer" of the organization.  Organizations need to evaluate if they have the right talent to move from the legacy IT stack to the new continuous IT stack.  This is certainly a challenge and will need some analysis from organization to organization.

I like his comparison of the IT stack rule with the rule defined in Isaac Asimov's, "I, Robot".

The Four Laws of Continuous Everything

1. No appdev process shall be implemented that can't be fully automated.
2. If an app, or process, can be rewritten to take advantage of new technology and improve its operation or maintenance, it should.
3. When an app, or process, can be replaced with a third-party service, it should.
4. When the Second or Third Law are limited by the First Law, look to the Second and Third Law to automate more.

This is certainly something I will start incorporating in my think about the continuous IT stack and how we need to start moving towards a more dynamic and agile architecture.

Reference

Wall, Quinton (2016). How to succeed in the new connected-everything continuous IT stack..  Retrieved August 28th, 2016 from http://www.infoworld.com/article/3024257/mobile-technology/how-to-succeed-in-the-new-connected-everything-continuous-it-stack.html

Layers in EA

I found this article from Graves (2013) interesting as it challenges the idea of layers in EA.  He shows the layers from Archimate, TOGAF, Zachman and ADM which can have any where from 3 to 5 layers (Data, Information, Data, Application, Technology.)  Some of the frameworks will combine or split out layers as needed.  He also goes on to say with Zachman you can have more layers depending on interpretation.  He goes on to say, "the correct answer to the 'how many layers' question is 'none."

Graves feels that using layers can have unattended consequences and can be misleading when looking at a particular view.  He uses the "Penrose Triangle" as an example of how things can look correct from one viewpoint but not from another.  I think what he is saying you can't just look at architecture from a single viewpoint and you need to make sure to use the full context of the enterprise.

I'm still digesting his article as it has a great deal of information in it and really challenges the idea of using layers.  While at this point I think viewing EA in layers is very beneficial, I will continue to digest his article and see how his perspective might be beneficial.

Reference

Graves, Tom (2013). On layers in enterprise-architecture.  Retrieved August 31st, 2016 fromhttp://weblog.tetradian.com/2013/12/11/on-layers-in-ea/

Security at an Integrated Layer

Like most people outside of the Security team, I get frustrated when "Security" requires additional to application development, integration or wants to know how data is protected.  I think this article from Rerup (2016) starts to highlight why the frustration exists.  Like the article suggests, Security many times is an afterthought or something that is reviewed prior to production deployment.  While I do get frustrated with security requirements, it is becoming more an more important to include security as an integrated layer in all layers of EA.  I like how Rerup positioned Security Architecture as a part of Governance Strategy, this gives it a more arching view then making it just another layer. 

He goes on to talk about how each layer of the IT stack has some sort of security aspect that needs to be addressed.  I think we need to start embracing security and make sure it is an integrated part of the whole EA framework. Every organization is one breech way from being out of business or taking a large integrity hit.  It is no longer enough to be security conscious, we need to bake in security to all of the business processes and not skimp on the details.

In my organization we are working evaluating the SANS Top 20 and will spend the next 3 years baking those best practices into our architecture to make sure we are doing everything to protect our organization from a potential future breech.

Reference

Rerup, Neil (2016). Why is Security Architecture separated from other Architectures? Retrieved August 31st, 2016 from https://www.linkedin.com/pulse/why-security-architecture-separated-from-other-neil-rerup