In the late 1980’s many interoperability problems, among systems and other similar issues, became very apparent while dealing with large architectures at the Department of Defense. According to (Global Security, 2010) soldiers had to use pay phones and other electronic devices from home to communicate with the Pentagon, due to the inability of several systems to interchange communications and/or data.

The 1991 Gulf War highlighted more difficulties of interoperability when our Armed Forces could not find the SCUDs and many systems still did not fully work together as planned (PBS, 2010).

The need for a framework to help the decision making process became urgent. To accomplish this, the Architecture Working Group (AWG) was created. This team was comprised of representatives from every command, service, and agency across the Department of Defense. The C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) Architecture Framework 1.0 was the initial product of this working group (Dam, 2015).

After this first release the working group received thousands of comments and corrections from many sources. As a result of that and other circumstances like the Y2K problem, during the next years the framework evolved originating the DoDAF V2.02 on 2012.

The DoDAF has been especially formulated to address the Department of Defense six cores (Ertaul & Hao, 2009):

1. Joint Capability Integration and Development System (JCIDS); to ensure the capabilities needed for war missions are identified and met. If gaps between required and actual capabilities are identified, measures must be taken to fill them.
2. Defense Acquisition Systems (DAS); to manage investments as a whole.
3. System Engineering (SE); balance system performance with total cost ensuring developed systems match capability requirements.
4. Planning, Programming, Budgeting, and Execution (PPBE); plays important role from the initial capability requirement analysis to decision making for future programs.
5. Portfolio Management (PfM); it deals primarily with Information Technology investments. It is meant to maximize return on investments while reducing risks.
6. Operations; define the activities and their inter-connections supporting the military and business operations carried out by the DoD.

It considers these basic concepts:

• Models: useful for the visualization of architectural data. They could be documents, spreadsheets, dashboards or other graphical representations. Serve as templates for organizing and displaying data.
• Views: data collected and presented in a model.
• Viewpoints: organized collection of views, usually representing processes, systems, standards, etc.

The framework acknowledges eight viewpoints as following (Dam, 2015):

The following diagram illustrates the relationships between models, views and viewpoints.

DoDAF provides a six-step process for developing architectures. This is not a detailed architecture development process; instead, it is an overview (Dam, 2015). The framework is missing a detailed methodology. Usually TOGAF is used to complement this framework.

As the field of EA grows, more corporations are starting to use EA to gain competitive advantage and to be able to adapt themselves to the continuous changes in the business environment and technology. To develop the architectural vision of any organization, a single framework usually is not enough, knowing or getting familiar with multiple frameworks become very helpful. Change is constant and the EA frameworks must evolve as environments transform.

References

Dam, S. H. (2015). DoD Architecture Framework 2.0. Manassas, VA 20109: SPEC Innovations.

Ertaul, L., & Hao, J. (2009). Enteprise Security Planning with Department of Defense Architecture Framework (DODAF). Hyaward, California.

Global Security. (2010). Operation Urgent Fury. Retrieved from GlobalSecurity.org: http://www.globalsecurity.org/military/ops/urgent_fury.htm

PBS. (2010, August). FRONTLINE. Retrieved from pbs.org: http://www.pbs.org/wgbh/pages/frontline/gulf/weapons/scud.html

Cloud computing combines the best of the mainframe era with the best of the PC-enabled client-server era along with the Internet era (Kavis, 2014). If managed correctly, cloud computing can provide central control governance plus a massive amount of distributed computing resources, broad network access over the Internet and those services may be paid as if they were a utility, like water or electricity.

The National Institute of Standards and Technology (NIST) (Mell & Grance, 2011) defines Cloud Computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”.

NIST cloud model defines five essential characteristics, three service models and four deployment models. The next diagram illustrates the NIST cloud computing framework.

To determine whether an IT service is a cloud solution, it must meet all five essential NIST characteristics. After the service satisfactorily meets all five characteristics, the service and deployment model may be determined. Service and deployment models do not factor into the determination of whether an IT service is cloud computing (Gartner, 2014).

Cloud computing is probably the biggest technological shift since the personal computer and the wide adoption of the Internet, but Cloud computing is still in its infancy; it is needing standards and best practices.

“It is important to distinguish the term “cloud” and the cloud symbol from the Internet. As a specific environment used to remotely provision IT resources, a cloud has a finite boundary. There are many individual clouds that are accessible via the Internet. Whereas the Internet provides open access to many Web-based IT resources, a cloud is typically privately owned and offers access to IT resources that is metered” (Erl, Puttini, & Mahmood, 2013).

“Cloud computing adoption is not trivial. The cloud computing marketplace is unregulated. And, not all products and technologies branded with “cloud” are, in fact, sufficiently mature to realize or even supportive of realizing actual cloud computing benefits. To add to the confusion, there are different definitions and interpretations of cloud-based models and frameworks floating around IT literature and the IT media space, which leads to different IT professionals acquiring different types of cloud computing expertise” (Erl, Puttini, & Mahmood, 2013).

Gartner research (Gartner, 2015) found these conclusions about Cloud technology for 2016:

• Hybrid will be the most common usage of the cloud — but this requires the public cloud to be part of the overall strategy.
• The defensive stance that dominated the large software vendor strategies toward the cloud has been replaced in recent years with a cloud-first approach. Today, most vendor technology innovation is cloud-centric, with the stated intent of retrofitting the technology to on-premises.
• Failure to put the people and processes in place to consistently leverage the security advantages of cloud computing can easily create workloads that are less secure than those created by traditional computing practices, resulting in unnecessary compliance incidents and data losses.
• As more applications move to public cloud environments, confidence in their use will increase. The ecosystems required to support mission-critical enterprise use cases will expand, reinforcing the viability of public cloud services as a destination for mission-critical workloads.

Cloud computing is taking center place, affecting Information Technology and Business environments in all organizations. Enterprise Architecture needs to lead and coordinate the efforts for building and developing a cloud strategy leveraging its advantages and capabilities.

References

Erl, T., Puttini, R., & Mahmood, Z. (2013). Cloud Computing: Concepts, Technology & Architecture. Pearsons Education. Kindle Edition.

Gartner. (2014, November 1). PBGC Enterprise Cloud Computing Strategy – Template.

Gartner. (2015, December 8). Predicts 2016: Cloud Computing to Drive Digital Business.

Kavis, M. (2014). Architecting the Cloud: Design Decisions for Cloud Computing Service Models. Wiley. Kindle Edition.

Mell, P., & Grance, T. (2011, September). The NIST Definition of Cloud Computing.

Chapter 52, Architecture Skills Framework of The Open Group Architecture Framework book (The Open Group, 2014), provides a set of role, skill and experience norms for staff undertaking architecture work.

TOGAF presents the following as job description for an enterprise architect:

“The architect has a responsibility for ensuring the completeness (fitness-for-purpose) of the architecture, in terms of adequately addressing all the pertinent concerns of its stakeholders; and the integrity of the architecture, in terms of connecting all the various views to each other, satisfactorily reconciling the conflicting concerns of different stakeholders, and showing the trade-offs made in so doing (as between security and performance, for example).

The choice of which particular architecture views to develop is one of the key decisions that the enterprise architect has to make. The choice has to be constrained by considerations of practicality, and by the principle of fitness-for-purpose (i.e., the architecture should be developed only to the point at which it is fit-for-purpose, and not reiterated ad infinitum as an academic exercise).” (The Open Group, 2014).

TOGAF considers Enterprise Architecture as a superset of Business, Data, Application and Technology Architecture. It states also that in cases where a team of architects is deemed necessary, a lead enterprise architect should be assigned to manage and lead the team members (The Open Group, 2014):

• The Enterprise Architect
• The Segment Architect
• The Solution Architect

I want to focus in this post on the Solution Architect: he/she “has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.” (The Open Group, 2014).

At my workplace, the Solution Architecture team, to which I belong; has the responsibility of ensuring that a project follows all aspects of the internal Technical Enterprise Process from initiation to closure while aligning the project deliverables with the company’s strategic goals and tactical objectives. In an attempt to be concise, the Solution Architect role is defined as Problem Solver. Identifying solutions by collaborating with the Information Technology and Business teams. Wanting to graph the scope of the Solution Architecture, the following diagram (Enterprise Systems Engineering, 2011) somehow represents my organization:

• EA: Enterprise Architect
• TA: Technical Architect; kind of representing the TOGAF Segment Architect role.
• SA: Solution Architect

The Gartner Enterprise Framework mentions another way of seeing Solution Architecture; it presents three viewpoints and a “meta viewpoint” (Bittler, 2016):

• Business Architecture Viewpoint
• Information Architecture Viewpoint
• Technology Architecture Viewpoint
• Solution Architecture “Meta Viewpoint”

Solution Architects are becoming vital in a world that is changing constantly, where technology is ubiquitous and the complexity of IT systems is increasing dramatically.

Mindi Clews from Equinox IT, published in the web an article “What makes a damn good solution architect?” in which a set of 8 different skills are numbered as following (Clews, 2015):

1. Damn good solution architects are expert communicators
2. Damn good solution architects have technical pedigree
3. Damn good solution architects bring a breadth of experience
4. Damn good solution architects zero in on risk
5. Damn good solution architects helicopter and deep dive
6. Damn good solution architects are pragmatic
7. Damn good solution architects fight for the right solution
8. Damn good solution architects are lifelong learners

A question came to my mind: Am I a damn good solution architect? If not what am I missing?

References

Bittler, R. S. (2016, January 31). The Gartner Enterprise Architecture Framework, Class Presentation.

Clews, M. (2015, June 6). What makes a damn good solution architect? Retrieved from Equinox IT: http://www.equinox.co.nz/blog/what-makes-a-damn-good-solution-architect

Enterprise Systems Engineering. (2011, September 19). Difference Between Architecture Roles. Retrieved from sysarchitect.com: http://sysarchitect.com/2011/09/19/differences-between-architecture-roles/#respond

McSweeney, A. (2014, June 9). Structured Approach to Solution Architecture. Retrieved from SlideShare: http://www.slideshare.net/alanmcsweeney/structured-approach-to-solution-architecture

The Open Group. (2014). TOGAF Version 9.1. Van Haren Publishing.

A couple of weeks ago, while attending my online EA 872 class, Professor Dr. David Fusco mentioned and recommended Jim Collins book “Good to Great”. I have to confess, until then; I never heard about that publication nor about Jim Collins. Shame on me.

“Good to Great” examines the reasons which make some companies and leaders escalate to superior results. Can a good company become a great company and, if so, how? (Collins, 2001)

“Leadership utilizes social processes to enlist the support of others to accomplish a shared task. Leadership combines vision in a way that allows other to contribute. Transformation leadership combines the expected stages of patience, persistence, perseverance, and pain (i.e. resistance, obstacles, etc.), before finally prevailing.” (Fusco, 2016)

Level 5 Leadership, what Collin calls his directorship empirical findings; embodies an apparent self-contradictory mix of humility and professional will. Those leaders, do have ambitions, but first and most for their leading organizations, not for themselves.

Collin’s analysis demonstrated that every good-to-great company had Level 5 leadership during vital or critical transition years. The research (Collins, 2001), overwhelmingly showed that Level 5 leaders, display diligence, compelling modesty, almost fanatical eagerness for achieving sustained results; they attribute success, to factors others than themselves; and when things go poorly, take full responsibility, blaming themselves.

Reaffirming that Level 5 is an empirical finding, not an ideological one (Collins, 2001); Level 5 leaders are a study in duality, like a symmetry between modesty and willfulness, humbleness and fearlessness:

HUMILITY + WILL = LEVEL 5

References

Collins, J. (2001). Good to Great. HarperCollins.

Fusco, D. (2016, February 4). Understanding Business Context EA 872 Class Presentation.

“Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model” (Ross, Weill, & Robertson, 2006).

“Enterprise Architecture = Strategy + Business + Technology” (Bernard, 2012).

“Enterprise Architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise Architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes” (The Federation Of Enterprise Professional Organizations, 2011).

“There are now business architects, security architects, application architects, data architects, information architects, integration architects, enterprise architects, infrastructure architects, domain architects, IT architects, solution architects, integration architects, the list seems endless” (Wierda, Mastering ArchiMate, 2014).

Many definitions about Enterprise Architecture have been written through the time of its existence; at the same time, various methodologies and frameworks have arisen; among them, TOGAF, Zachman, Gartner, MODAF, DYA, DoDAF, FEAF, etc. but in many cases Enterprise Architecture as a discipline, has failed to deliver the intended results (Wierda, Chess and the art of Enterprise Architecture, 2015).

Enterprise Architecture is about managing complexity, preventing IT chaos, aligning business and IT strategy and making sure the business profits from the IT enabled opportunities. According to Michael Porter (The Federation Of Enterprise Professional Organizations, 2011), more than 80% of organizations have problems executing their business strategy, the problem is not the strategy but an ineffective execution. EA provides the means for correcting that.

Successful companies have what (Ross, Weill, & Robertson, 2006) calls Foundation for Execution. To create an effective foundation for execution, the same authors recommend that companies must master these three key disciplines:

• Operating Model: the adequate level of business process integration and standardization for delivering products to customers.
• Enterprise architecture: logic behind the organization of business processes and IT infrastructure to reflect and achieve the integration and standardization requirements of the company’s operating model.
• IT engagement model: governance mechanisms to ensure that local and companywide objectives are achieved by business and IT projects.

Enterprise Architecture is very important and useful, helping organizations to gain foundation for execution and competitive advantages. If it fails is not because the discipline failed, but because the ones applying it failed (Gartner, 2009).

References

Bernard, S. A. (2012). An Introduction to Enterprise Architecture. Author House.

Gartner. (2009, September 2). Newsroom. Retrieved from Gartner: http://www.gartner.com/newsroom/id/1159617

Ross, J. W., Weill, P., & Robertson, D. S. (2006). Enterprise Architecture as Strategy. Boston: Harvard Business Review Press.

The Federation Of Enterprise Professional Organizations. (2011). A Common Perspective on Enterprise Architecture. Retrieved from FEAPO: http://feapo.org/wp-content/uploads/2013/11/Common-Perspectives-on-Enterprise-Architecture-v15.pdf

Wierda, G. (2014). Mastering ArchiMate. R&A .

Wierda, G. (2015). Chess and the art of Enterprise Architecture. R & A.

At my workplace’s Book Club, while reading the TOGAF book (The Open Group, 2014)  one of my colleagues sent me this very nice picture regarding the reviewing chapter for that week:

The phrase is mentioned under the Approach subtitle of Chapter 16 (Phase H: Architecture Change Management), which specifies the following objectives for the mentioned facet:

• Ensure that the architecture lifecycle is maintained
• Ensure that the Architecture Governance Framework is executed
• Ensure that the enterprise Architecture Capability meets current requirements

“In Phase H it is critical that the governance body establish criteria to judge whether a Change Request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method (ADM). It is especially important to avoid “creeping elegance”, and the governance body must continue to look for changes that relate directly to business value.” (The Open Group, 2014).

Consulting to my best friend Google, I have found this definition: “In software development, creeping elegance, related to creeping featurism and second-system effect, is the tendency of programmers to disproportionately emphasize elegance in software at the expense of other requirements such as functionality, shipping schedule, and usability.

Creeping elegance is also forced by customers and sales personnel in the last stages of software development. Often one comes up with “just another feature” before the delivery date, and the software developer is left with the hopeless case of prioritizing between delivery on time according to schedule or to fully satisfy customers and/or sales department.” (Wikipedia, 2011).

The application of good governance based on (TOGAF, n.d.):

• Discipline: adhere to procedures, processes and authority.
• Transparency: availability for inspections by authorized parties.
• Independence: avoid conflict of interests.
• Accountability: actions and decisions must be accountable.
• Responsibility: acting responsible toward the organization and stakeholders.
• Fairness: do not create advantages for any party involved.

Will avoid this kind of issues and will help to keep the focus on the value added to the business, because Enterprise Architecture does not operate in a vacuum.

References

Ross, J. W., Weill, P., & Robertson, D. S. (2006). Enterprise Architecture as Strategy. Boston: Harvard Business Review Press.

The Open Group. (2014). TOGAF Version 9.1. Van Haren Publishing.

TOGAF. (n.d.). Architecture Governance. Retrieved from Open Group: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap26.html

Wierda, G. (2015). Chess and the art of Enterprise Architecture. R & A.

Wikipedia. (2011, February). Creeping_elegance. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Creeping_elegance

Woodworth, P. A. (2013). A Reference Architecture for Enterprise Architecture. Kindle Edition.

Not too long ago, while working on a project, the development team required a particular functionality to complete the work. The mentioned capability was required to be available to any of the company’s systems and to be up to date most of the time (the aimed goal was 100%). Many solutions came to the table, but at the end of the day, the real two alternatives were to build or to buy. Another option, which in this case was not available, but it is worthy to mention is Open Source (Hwangbo, 2013).

After a fast research, it was found that there were many software companies providing the required information, mainly as Software as a Service (SaaS), where the consumer is to use the cloud provider’s application running on its cloud infrastructure (Rafaels, 2015).

Build, buy, customize (open source or company’s packages) options have been challenging management for a long time and thousands of lines justifying one or the other alternative have been written.

During the evaluation process, I have found the following table, which has been adapted from (Wong, Maoz, & Desisto, 2015) very useful (Capabilities of Buy, Customize and Build Options):

In this case, the final choice, was the buy option (customization was out of the picture). The decision was based mainly on these criteria (Cohn, 2014):

• Budget, considering the total cost of ownership.
• The company’s technical proficiency on this particular matter. Specially for maintenance.
• Time constraints. The development team did not have enough time to build the desired application.
• The software needed was available without any modifications. No need for additional features.
• Building the software would have not created any competitive advantage for the company.

References

Cohn, C. (2014, September 15). Build vs. Buy: How to Know When You Should Buid Custom Software Over Canned Solutions. Retrieved from Forbes : http://www.forbes.com/sites/chuckcohn/2014/09/15/build-vs-buy-how-to-know-when-you-should-build-custom-software-over-canned-solutions/#7b45cb5c4849

Hwangbo, H. (2013, October 21). Enterprise Architecture for Emerging Technology: Build, Buy or Open Source. Retrieved from Emerging Technology Blog: http://usblogs.pwc.com/emerging-technology/enterprise-architecture-emerging-technology-build-buy-open-source/

Rafaels, R. (2015). Cloud Computing From Beginning to End. Lexington, KY: Ray Rafaels.

Wong, J., Maoz, M., & Desisto, R. (2015, March 05). Key Considerations in the Decision to Buy, Build or Customize Enterprise Mobile Apps. Retrieved from Gartner: http://www.gartner.com/document/2999118?ref=solrAll&refval=162179990&qid=50117e172f34528760c6ceaf6b3792c4

An overseas company around 2003, in search of business vertical integration and willing to enter the metal building industry in the USA, bought a very well known Kansas City MO, manufacturing business. Later on 2008, it also bought one of the main competitors in another state attempting to get a bigger market share.

The two American companies had very different cultures but somehow similar technologies; they both were supposed to keep their brands. The merging process started by attempting to put together the engineering and IT teams, unfortunately this process really became a tag of war, lasted more than six years and cost more millions than expected.

Common story? Merger and Acquisition (M&A) literature is vast and spans for more than half a century, but still many of these cases are excessively painful and costly.

Both manufacturers were well recognized in their markets, had good engineering teams; but they lacked good costs and processes control.

During 2003, the new owner; to achieve automation of their core business processes and to modernize the operations started implementing an ERP system. When the second acquisition came, it was already running, even though with too many customizations that later impede system upgrades and did not help the merging as envisaged.

Defining an Operating model as explained in (Ross, Weill, & Robertson, 2006) Chapter 2; could have been useful in this case?

Definitively, yes.

Defining an operating model may have provided the necessary levels of business process integration and standardization for product, services delivery and for the merging.

Looking at the four operating model examples (Ross, Weill, & Robertson, 2006):

• Coordination
• Diversification
• Replication
• Unification

Management, (knowingly or not) tried to apply a Unification model. This could have worked before the merging, but when bringing the new organization on board a little switch toward a Coordination model and a broader consideration of the human factor (Fusco, 2016) may have saved time and money.

Handling the intricacies of a merge and/or an EA implementation, may become overwhelming, as mentioned in (Wierda, 2015), considering these principles will provide the means to fight complexity:

• Scenario planning (forecasting and back-casting)
• Requirements over principles
• Collaboration over division of labor
• Design skills over design principles
• Structure documentation (models) at the core
• Risk based abstractions
• Check and balances at the governance architecture level.

References

Fusco, D. (2016, January 21). Launching EA Initiatives. Pennsylvania.

Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy. Boston, Massachusetts: Harvard Business School Press.

Wierda, G. (2015). Chess and the art of Enterprise Architecture. The Netherlands: R&A.

Human beings routinely execute a variety of complicated task as routine, without even thinking about them. Functions like breathing, walking, driving, etc. become second nature.

Taking this analogy (Ross, Weill, & Robertson, 2006) defines Foundation for Execution as “the IT infrastructure and digitized business processes automating a company’s core capabilities”.

“Paradoxically, digitizing core business processes makes the individual processes less flexible while making a company more agile”.

When looking back at some companies I worked for, I realized that they had in place many independent solutions for single strategic initiatives. Some of their systems do the same thing in a different way and focus on similar customers. Their business objectives are still loosely aligned to the IT capabilities. I believe that these issues are not rare among US enterprises, on the contrary having what (Ross, Weill, & Robertson, 2006) defines as Foundation for Execution is more unusual than we may imagine.

References

Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy (Kindle Edition ed.). Boston, Massachusetts: Harvard Business Review Press.

This blog originated as a requirement for my EA 872 class of the 2016 Spring semester at Penn State University. I am glad to start this blog about my Enterprise Architecture learning experiences.

Thanks in advance for your comments and suggestions.