Post 11: Is IT a Safe Harbor for Your Organization’s Data?

How is the European Safe Harbor ruling affecting your IT strategy, I&O function, and cloud computing / data storage practices? If this is new to you, last year there was quite some fuss over “a court ruling striking down rules for data transfer between the U.S. and Europe [that] will create short-term uncertainty for data center service providers…” (datacenterfrontier.com).

Figure 1. Google search, extremetech.com

According to Forbes, “The court ruled that even if US companies are taking adequate protection measures (and studies show that many are not), the US public authorities are not subject to the Safe Harbor guidelines, thus putting European citizens’ data privacy at risk to US government surveillance” (forbes.com). I have to admit, I didn’t know what Safe Harbor meant when it first came up. As an Enterprise Architect, do we too often overlook security and data privacy matters? Should we pay more attention or leave it to the legal and security guys?

EA Impact?

Where I work, it didn’t take long for functions around Legal, Audit and IT security to respond. There was much more scrutiny on where existing and future data was to be stored. This meant scouring our asset portfolio and service providers to ensure we were on top of the problem. Practically speaking, as an EA working for an international company with a Corporate HQ in France, I’ve not been affected as much as others. Aside from helping to examine which systems might be adversely affected, we mainly kept this security factor in mind during all new vendor and software selection activities. It meant that any cloud hosting provisions by the vendors we were validating had to be anchored in European data centers to ensure the Safe Harbor rules were being followed. How has your organization or EA practice been affected?

Resolution in the Works

As of February 2016, a resolution to the business crisis was reached between EU and US officials, but there’s no obvious time frame for ensuring the agreement is a done deal. Now “the European Commission and US administration must now show total commitment to implementing this agreement and getting trans-Atlantic data flows back onto a secure and stable legal footing” (BBC).

References:
(1) Safe Harbor Ruling. http://datacenterfrontier.com/what-the-european-safe-harbor-ruling-means-for-data-centers/
(2) Safe Harbor Update. source: http://www.bbc.com/news/technology-35471851
(3) http://www.forbes.com/sites/riskmap/2015/10/27/the-eu-safe-harbor-agreement-is-dead-heres-what-to-do-about-it/#40d0bbdb7171

Post 10: Technology Architecture, Virtualization and Docker

This past week my graduate class has been discussing the technology stack and in particular we fell on the subject of IT Infrastructure and Operations (I&O). I&O is usually responsible for an organization’s data center facilities among its many other hats. We were discussing how I&O has been affected by data center modernization like virtualization and concepts that go hand in hand with cloud hosting such as multi-tenancy/resource pooling and rapid provisioning and elasticity. Just to keep reminding me how fast technology advances occur when my head’s turned the other direction, the professor and a few students began discussing something called Docker. I’ll come back to that.

Factoring unpredictability and agile environments

Some I&O functions may have established a policy and process to replace or modernize certain infrastructure, say physical servers, every 3 years. This was my experience working with I&O and IT engineering during the early 2000s prior to advances in and mainstream shift to virtualization. Whatever the internal I&O processes are, it’s important to note that too much focus on process without consideration for the people and technology is ineffective. People across the organization are trying to innovate and deliver faster, including IT people. Technology advances quickly and IT needs the capabilities to be more adaptive, agile, and responsive. If it takes IT weeks to spin up a new environment, this sets each corresponding IT function further and further behind before stakeholders can perceive a return on investment.

Back to Docker

The latest “as a service” acronym appears to be Containers-as-as-Service (CaaS) and this is where Docker comes back into the discussion. Docker is a CaaS offering that involves cloud, virtualization, and application delivery, but what is it and how does it compare with existing technologies? The Docker platform enables IT developers, administrators, and other technical engineers to build, ship and run distributed applications…anywhere and on any platform. Compared to modern virtualization capabilities, there is a prospective bump to agility, portability and control that comes with the ability to provide a total environment for application isolation in a complete, self-contained unit that can run on any Operating System and hardware platform. I haven’t really come to appreciate all the potential and use cases for this, but I see Docker (or other Application Container solutions), and CaaS as one more cloud/data center evolution that IT organizations can employ to meet and respond to business demand.

           
Figure 1, source: https://www.docker.com/what-docker

In figure 1, the left image represents a typical virtualization scenario while the right side is Docker. Notice the absence of the guest OS and hypervisor layers under the Docker model. Even so, Docker technology can be combined with other contemporary virtualization as well. For example, Citrix has added Docker container support to its proprietary version of XenServer, so the technologies appear to marry and compliment each other as well.

How are you using Container virtualization, Docker, or CaaS in your organization? What are the practical Container use cases for IT departments to provide to the average medium and large manufacturing business?

References:
(1) Docker. https://www.docker.com/what-docker
(2) Citrix. https://www.citrix.com/blogs/2015/05/12/xenserver-v65sp1/

Post 9: Internet of Things – Cloudy with a Chance of Fog

As a technology company, Cisco is probably best known for its networking technologies. As an enterprise architect working in a manufacturing organization, I’ve had the chance to catch a number of presentations from Cisco over the past year concerning their cloud and fog computing technologies. With so many organization’s poised to realize opportunities to leverage vast amounts of new data collection, companies like Cisco seem ready to provide technologies to help. All that data can be expensive to transmit, store, and process, miles away from where it’s generated. But, if remote construction sites, plants, quarries, and other businesses could leverage data at the edge, that is, closer to the ground where it’s being generated, these organizations could benefit in a multitude of strategic and tactical ways.

If fog computing is something unfamiliar, here’s an overview from Cisco. Fog computing extends the “cloud” metaphor by referring to the fog as the technologies that operate closer to the edge where big data is being generated. As Cisco puts it, fog–which is synonymous with Edge Computing–is being positioned to deliver on three major opportunities:

1. Analyze the most time-sensitive data at the network edge, close to where it is generated instead of sending vast amounts of IoT data to the cloud.
2. Act on Internet of Things (IoT) data in milliseconds, based on policy.
3. Send selected data to the cloud for historical analysis and longer-term storage.

The article does a good job explaining how a anticipated explosion in new IoT devices capable of generating data will create new opportunities for firms but also pose new challenges for harnessing the flow. Cisco’s strategy is a new kind of infrastructure designed specifically for the IoT and the estimated 50 billion “things” that may be connected to the Internet by 2020.

References:

http://newsroom.cisco.com/feature-content?articleId=1613641&type=webcontent

Post 8: Enterprise Architecture as Strategy

I am frequently looking for simple ways to explain Enterprise Architecture (EA) to stakeholders inside and outside of IT who have some preconceived notion that EA should be to pigeonholed with IT modeling. Awhile back I read the title Enterprise Architecture as Strategy (J. Ross, P. Weill, and D. Robertson) which provides a pragmatic and powerful description of what they coined the “foundation for execution” which is composed of three critical concepts:  Operating Model, Enterprise Architecture, and IT Engagement Approach. These can be briefly summarized as follows:

1. Operating model:  the necessary level of business process standardization and integration required in an organizational planning unit.
2. Enterprise Architecture:  is the organizing logic for business processes and Information Technology (IT) components, which reflect the planning unit’s operating model.
3. IT engagement model:  is the system of governance mechanisms that serve to align the strategic objectives of the firm with those of IT.

This is all well established and illustrated in the following figure:

I found a favorable review of the book from B. Gils, who himself happens to be an well established architect and thought leader from EA tool supplier BizzDesign. Check out more from their running blog here on the BizzDesign site.

The one issue Gils mentions with the referenced book is focused mainly on IT. I didn’t have this objection myself nor did I draw this conclusion. I think the book spends a fair degree of time establishing the importance of understanding the core business processes and corporate strategies of the underlying motivation for IT to begin with. He also suggest that it misses the point about understanding the importance of strategy, e.g. competitive strategy. I think this part is okay as well considering that there’s enough material from Porter on defining strategy and each of us has to understand what it means to our own organizations and projects. Trying to spend too much time defining what strategy is or should be to a firm would lose the focus on the authors’ intent to define the Foundation for Execution.

References:

Enterprise Architecture as Strategy. (2006, J. Ross, P. Weill, and D. Robertson). http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398

Strategic Architecture Blog (2008, B. Gills). http://strategic-architecture.blogspot.com/2008/11/enterprise-architecture-as-strategy.html

Post 7: IT Operating Model

Early in my architectural journey, a colleague introduced me to “operating models.” At first, I had a hard time differentiating operating models from business models. Later I came to understand that an operating model was a subset of a business model and could help define the level of business process standardization and integration necessary to function and deliver to stakeholders. Operating models are not static, they evolve to meet the transformational needs of the planning unit in its environment. This was a paradigm shift for me because I was finally able to conceptualize how one or more business functional units might consider their processes requiring more or less standardization and integration requirements. Operating models have been at the core of firms benefiting from implementing ERP systems for the past 20 years or more, and they seem to be driving further standardization and integration in other areas of the business as well.

Enterprise Architects, especially those embedded in an IT department, should not ignore the fact that IT also has an operating model and should be subject to the same scrutiny and standards as other parts of the firm. Yan Zhou’s recent article on The Open Group blog highlights her viewpoints on how the traditional IT value stream known as “Plan, Build, Run” should be recognized for its own transformational shift.

According to Zhou, “IT is becoming one business segment inside an enterprise with its own mission and goals to achieve instead of being only in a supporting role as before.” Zhou presents a reference model, figure 1, with a new process segment called “stakeholders” as an extension to the Plan/Build/Run operating model.

Figure 1. Zhou, Y (2016). IT Operation Reference Model.

I really appreciate many of the pragmatic details Zhou presents in her blog entry. Part of Zhou’s message seems to suggest that IT needs to recognize its has it’s own operating model which should stem from a service oriented approach. Despite covering a lot of territory and interesting details, I have a hard time finding the article to really break much, if any, new territory. For one thing, the pillar defined as “stakeholders” isn’t new to IT. All of the defined capabilities of this stakeholders pillar already exist under the “plan” pillar of IT and co-exist between those responsible for helping stakeholders navigate from strategy to portfolio. We could abstract the entire pillar under planning as a capability called stakeholder management or business engagement. As suggested by Zhou, the lifecycle of IT is such that stakeholder management continues to permeate and coexist with the other major phases of the IT value stream, but this neither lends itself to the necessity to define another value stream called stakeholders. If anything, stakeholder management is simply a normal capability of any support or service-oriented support function.

References:

Zhao, Y. The New Generation IT Operating Model.  http://blog.opengroup.org/2016/02/05/the-new-generation-it-operating-model/?blogsub=pending#blog_subscription-3

 

Post 6: The Importance of Requirements in Understanding the Architecture Vision

Enterprise Architecture is frequently concerned with requirements–both the ones behind the existing portfolio of solutions as well as the future state opportunities.

While reading about requirements management strategies this past week, I came across an older but relevant entry from Serge Thorn’s blog which sets the premise that “the objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases.” As pointed out in his post, obtaining future state requirements is not always so cut and dry. Thorn suggests a combination of aggregation and collection methods to tease out the following categories:

• Business and Functional requirements – the fundamental needs of the service or product which is to be delivered. Recommended technique: Business Use Cases
• Non-functional requirements. In my experience, these criterias such as performance and usability are often referred to as technical requirements. Non-functional requirements describe aspects or properties that the functional ones must have.
• Project constraints. These are described as time, resource or budget constraints. The main issue I have with these requirements is that they are often not understood at the point which EA is involved. Project constraints should be formalized during detailed planning activities once a project has been approved and prioritized within the portfolio of other projects to be implemented.
• Design and architecture requirements. These should include restrictions on how a solution is designed or where its data can be stored. The idea is that EA has existing standards and design patterns to be adhered to.
• Project drivers. Thorn describes these as “business-related forces” such as the purpose of the project. I have a hard time seeing this as something other than the goals of the project, which should be refined by project objectives and ultimately business functional requirements.
• Project issues. Here’s another type of requirement I have trouble getting behind. Thorn describes these as “the conditions under which the project will be done” but there is no practical example by which to understand it.
• Testing requirements. Thorn recommends to begin planning testing requirements immediately. I probably have the biggest issue with this category because I would expect that testing requirements could only be written during the implementation phase of the project once development or integration of the solution has been performed to some degree. When EA is involved during the conceptual stage of projects, it seems unnecessary to me that testing requirements should be on anyone’s mind. Perhaps Thorn intended this one to be about testing the quality of a solution to meet a requirement which might be further validated through a demo or proof of concept.

In any case, Thorn suggests that there are solutions out there to help interface efforts in moving from requirements gathering, to aligning the enterprise architecture, to handing off to systems implementation and design. As someone who recently reviewed EA tools from Gartner’s 2015 magic quadrant, my impression is we have a long way to go before EA has a solution to effectively manage requirements.

References:
http://sergethorn.blogspot.com/2007/12/requirements-management-and-enterprise.html

Post 5: The Role of EA and Solution Development

In my experience as an enterprise architect, the mission of EA and the role of the architect is going to be tailored to what the organization needs and what the organization knows. A young EA practice begins working on the problems they can see with the stakeholders they have connections with. The work performed is likely to mirror the maturity of the practice itself, the experience of the architects, and the extent to which the practice is integrated and communicating with the business and IT functions around it.

I came across this post from Martin Fowler’s blog concerning “The Role of an Enterprise Architect in a Lean Enterprise.” Martin makes some excellent points concerning companies that are moving to more lean and/or agile IT practices and how this may serve to derail investments in EA practices. Martin’s makes numerous points about how development practices may ignore the standards and principles long established by EA and that governance and enforcement can prove problematic.

Since lean and agile sim to improve value outcomes through reduced waste and rapid feedback, Fowler’s message is to reinforce that EA is more important than ever. The main issue I have with this piece is the notion that EA creates the vision for the future state in relative isolation from the business. While there is a degree of future state planning in the technology pillar of EA that is absent business involvement, the majority of EA planning is driven by business strategy and the operating model of the organizational planning unit and its functions. Fowler’s blog also denotes a strong relationship between the EA and the software development teams. In EA, ideally there is another layer of solution architecture between EA and those responsible for the software architecture. The role of the solution architect should be to interface more closely with the software developers and to validate any deviations in the architectural standards back to EA. In the Enterprise–the firm–is small enough that these individual roles do not exist or are compressed, I would question the presence of an actual EA practice at all.

References:
http://martinfowler.com/articles/ea-in-lean-enterprise.html

Post 4: The Importance of Relationship Management in Supply Chains and EA

A high functioning EA practice has to have a good communications plan and strong relationship management. Understanding stakeholder strategies, needs and concerns is paramount. As an architect for a manufacturing organization, I’m always trying to better understand our supply chain and the array of capabilities that make it up.  Like EA, the supply chain thrives on relationship management, the ones that extend the organizational boundaries into suppliers and customers. Why is this important to me as an EA? Because if you work as an EA for a manufacturing organization, the supply chain and its related capabilities are paramount.

While researching the major processes involved in supply chain management (SCM), I came across Singh and Sohani’s whitepaper on “A Proposed Model for Integration of ERP, CRM, SRM and Supply Chain Management.”  The authors suggest there is significant confusion about what constitutes SCM, indicating that it is often viewed as  synonymous with inbound and outbound logistical processes, or as another name for some combination of purchasing, production/operations, and logistics. The authors propose a model (shown in figure 1) and series of definitions around processes and activities that comprise the model. Their argument is to better articulate what SCM processes are composed of so that we can better understand the integration importance

Figure 1. Singh and Sohani’s proposed model for integrating processes–ERP, CRM, SRM, and SCM–across the enterprise.

Their research concludes that “the structure of activities within and between organizations is a critical cornerstone of creating better supply chain performance.” That is, that we have to see the value stream far beyond the borders of our own corporate garden and that the digital fabric between these upstream and downstream organizations is critical.

I think the paper has difficulty drawing any specific, actionable conclusions. Despite this, I like the model and definitions represented around the end to end supply chain and its composition. In a sense, this article helps makes a pitch for acquiring and integrating a digital strategy around SCM and all related processes within ERP, CRM and SRM.

References
https://www.researchgate.net/publication/262936402_A_Proposed_Model_for_Integration_of_ERP_CRM_SRM_and_Supply_Chain_Management

http://wiki.scn.sap.com/wiki/display/SCM/SAP+SCM

Post 3: An approach to the business architecture layer: Business Capabilities

In their 2011 article on Business Capabilities, Ulrich and Rosen make a persuasive argument on a business architecture pattern that can provide immediate value to practitioners of EA:  the Business Capability Map. Accordingly to the definition shared, a business capability is a simple way to describe “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.” Capabilities can be decomposed into many contributing components:  organizational, information, processes, services, and resources/technology. By encapsulating the complexity of the business and the rest of the EA stack within the capability, a map can be constructed to better communicate with business stakeholders about what their main activities are (i.e. capabilities) and where their problems or investments may lie within the map. Like Ulrich, most examples of capabilities maps suggest going to deeper levels of capability definition over time. While a level 1 capability may simply describe Procurement Management as a capability of the Purchasing function, a level 2 capability of Procurement might be described as Vendor Management.

The figure provides a model of what many business capability maps like that from Ulrich proposes in order to start simply and decompose the business. You may be surprised when discussing such a map with functional stakeholders as to have a relatable model from which to start a discussion about technology investments.

A. Schank

References:
Ulrich, W. Rosen, M. (2011). The Business Capability Map: The “Rosetta Stone” of Business Alignment. Cutter Consortium on Business & Enterprise Architecture. Retrieved from https://www.cutter.com/article/business-capability-map-rosetta-stone-businessit-alignment-469506

 

Post 2: What’s the difference between my Enterprise Architecture and my digital strategy?

When you work in a business planning group as an Enterprise Architect, as I do, the term “strategy” can seem to worm its way into every other sentence. So I like to understand how strategy can be applied to different planning units–enterprises, products, business functions, IT, projects, etc.–in order conceptualize what strategies are truly strategic and why.

According to Johnson (2012), “Choosing the right digital strategy can improve your bottom line. Thinking through your goals and processes before you start a project can save you time, money and effort. Further, innovation to provide superior client service should drive any strategic or tactical technology initiative.” There you have it, in less than 50 words, Johnson expressed digital strategy in typical terms–goals, processes, project, innovation, strategic, technology initiative–that should fit very well with just about any practicing EA. Johnson goes on to quote the Wikipedia page, “A digital strategy is the process of specifying an organization’s vision, goals, opportunities and initiatives in order to maximize the business benefits of digital initiatives to the organization.” Now, the scope of an “organization” can mean many things, but that definition is starting to sound more and more like the EA proposition, isn’t it? Johnson’s article suggests three steps to a digital strategy:

1. First, find out where you or your client’s problem areas are, i.e. weaknesses. These are to be considered as opportunities.
2. Envision the ideal situation, how to improve the situation, or how to be more efficient.
3. Consider the initiatives and technologies necessary to enable these opportunities.

While Johnson argues that a digital strategy is essentially anything you would do differently to improve business performance, these days, many experts argue that a digital strategy is the synergistic result of social, mobile, analytics, cloud, and many other relevant technology paradigms such as big data and the Internet of Things. My own preference is not to assume that a digital strategy has to assume any specific mashup of technologies but is more in line with Johnson’s pragmatic description and approach which meshes very well with the objectives of EA.

A. Schank

References:
Johnston, R. (2012). Tips for a firm’s digital strategy. CPA Practice Advisor, 22(6), 18. Retrieved from http://search.proquest.com.ezaccess.libraries.psu.edu/docview/
1081991209?accountid=13158