Business Architecture Modeling

In this post, which is a continuation of my previous one; I want to comment some of the 101 lessons expressed by Roger Evernden in his book “101 Lessons from Enterprise Architecture”.

“101 Lessons from Enterprise Architecture is a bit tongue-in-cheek, and it’s certainly a departure from some of my other writings about the subject, but I hope you enjoy reading it as much as I enjoyed writing it!” (Evernden, 2015),

Value depends more on dynamic elements that static ones

“The components and structure of an architecture or design are important as a foundation. But without relationships and interfaces between the parts they lack energy.

A design is useful and worthwhile because it does something – it has a purpose. The static elements alone are like a mortgage: no-one wants a mortgage; they want what the mortgage offers, the possibility of buying a home.

Static elements provide a basis. The connections make it interesting – they provide dynamics, interaction, energy, and potential” (Evernden, 2015).

Dynamic is something capable of action and/or change; static on the other hand means fixed or stationary. EA requires change agents to drive toward the company goals and objectives.

Slow, Inaccurate and brilliant

“It was Einstein who first said that “Computers are incredibly fast, accurate and stupid. Human beings are incredibly slow, inaccurate and brilliant. Together they are powerful beyond imagination.”

Architectures and designs should work well with people. They should allow time for people to interact, to reflect, to think, and to imagine. Allow for people making mistakes, misunderstanding, losing concentration, and being brilliant” (Evernden, 2015).

Enterprise Architecture is not only about IT or business, it is about people doing things together.

Make Steady and sure progress

“Activities nearly always take longer than we expect. Work out how long you think it will take, and then add another 20 to 50%. And even then, half the time you will need to add another 20 to 50%.

The important thing is that we do make sure and steady progress – one step at a time – until the task is complete. Take the time to measure progress towards your target. If you’re not making progress, make the changes necessary to ensure progress towards a goal or objective” (Evernden, 2015).

(Ross, Weill, & Robertson, 2006) Indicates to build the foundation for execution one project at a time. A company may need a quick survival transition, but big or massive changes are costly and very risky.

Certainty is a rarity

“We rarely know exactly how people are going to use designs or architectures. Although we seek certainty, ambiguity is the norm.

Certainty may simplify, but it can also lead to predictable, dull and boring. Embrace uncertainty. It could be said that uncertainty, ambiguity, imprecise requirements and unclear goals are the type of things that drive creativity, innovation, and originality in our solutions” (Evernden, 2015).

Changes are the constant in the actual world. Many of the decision making in the enterprise are done as well educated guesses or considering the Latin phrase Ceteris Paribus.

There is no single solution

“The “correct” solution is always open to interpretation. It is always possible to think of alternatives. And it is always possible that there is a better solution; or a worse solution. And there’s always room for improvement. That’s how things evolve.

Look beyond your first ideas. Consider substitute or complementary ideas. Allow others to make suggestions and improvements” (Evernden, 2015).

EA faces complex problems for which solutions depend of their context and other multiple factors; architects need to make trade-offs.

Right or wrong

“Designs and solutions are appropriate, or unsuitable, fit for purpose, relevant, better or worse, good or bad, within budget or not, delivered on time or late – but not right and not wrong.

Wrong in one context might be right in another. Define criteria that can be used to evaluate a design to judge how well it meets the need or requirement. Also use these criteria to assess the relative merits of alternative designs” (Evernden, 2015).

“Good judgement comes from experience, and a lot of that comes from bad judgement” (Will Rogers).

I know that many of you, reading these lines will agree with the lessons expressed by Mr. Evernden; many others will not or not completely, but they surely are something to talk about and to keep learning.

References

Evernden, R. (2015). 101 Lessons from Enterprise Architecture. Kindle Edition.

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

Not too long ago a colleague recommended me a book authored by Roger Evernden titled “101 Lessons from Enterprise Architecture”.

(Evernden, 2015) Starts his introduction “Several years ago I came across a book by Matthew Frederick – “101 Things I Learned in Architecture School”. I started thinking about things that I had learned from Enterprise Architecture, and that’s how this book started. It doesn’t cover everything that I’ve learned from enterprise architecture, but it does cover some of the things that matter, a few that get overlooked, and some that were a challenge to write explain in a couple of paragraphs and a diagram”.

I am finishing my EA 872 Spring semester class at Penn State University and I started to think on all the lessons learned through this cycle.

• Working with Toolkits: to understand Enterprise Architecture complex issues which usually are having a variety of solutions, toolkits demonstrated to be extremely helpful. They are versatile, and adaptable resources.
• Expressing ideas in writing: anticipating the reader needs reflecting intellectual flexibility and maturity and evaluating the adequacy of the EA arguments and ideas.
• Hands on experiences: working on real EA artifacts, creating, adapting, and evaluating them; helped to understand the concepts of EA.
• Foundation for Execution: “a foundation for execution is the IT infrastructure and digitized business processes automating a company’s core capabilities” (Ross, Weill, & Robertson, 2006).

The list presented, of course is not exhaustive, it is the tip of an iceberg of learning experiences for which I am very grateful.

References

Evernden, R. (2015). 101 Lessons from Enterprise Architecture. Kindle Edition.

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

“Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” (Gamma, Helm, Johnson, & Vlissides, 2009). The “Gang of Four” introduced the principles of design patterns and offered a catalog of them. Their 23 patterns are considered the foundation for all other object oriented software design patterns.

“Patterns for system architecting are very much in their infancy. They have been introduced into TOGAF essentially to draw them to the attention of the systems architecture community as an emerging important resource, and as a placeholder for hopefully more rigorous descriptions and references to more plentiful resources in future versions of TOGAF” (The Open Group, 2014).

“In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so” (The Open Group, 2014).

“Pattern techniques are generally acknowledged to have been established as a valuable architectural design technique by Christopher Alexander, a buildings architect, who described this approach in his book The Timeless Way of Building, published in 1979. This book provides an introduction to the ideas behind the use of patterns, and Alexander followed it with two further books (A Pattern Language and The Oregon Experiment) in which he expanded on his description of the features and benefits of a patterns approach to architecture.

Software and buildings architects have many similar issues to address, and so it was natural for software architects to take an interest in patterns as an architectural tool. Many papers and books have been published on them since Alexander’s 1979 book, perhaps the most renowned being Design Patterns: Elements of Re-usable Object-Oriented Software. This book describes simple and elegant solutions to specific problems in object-oriented software design” (The Open Group, 2014).

(Erl, Cope, & Naserpour, 2015) Defines a design pattern as a proven design solution for a common design problem which is formally and consistently documented. The book aims to provide a master design pattern catalog for cloud computing. (Arcitura Education, n.d.) Presents a complete and actualized list of them.

“Cloud computing patterns are applied via the implementation of individual or combinations of different technology mechanisms. Together, the documentation of patterns and mechanisms provides an extremely concrete view of cloud architecture layers and the individual building blocks that represent the moving parts that can be assembled in creative ways to leverage cloud environments for business automation. Each design pattern in the cloud computing catalog is associated with one or more mechanisms” (Arcitura Education, n.d.).

According to (Erl, Cope, & Naserpour, 2015), design patterns, compound patterns and mechanisms relate to each other as following:

• Mechanisms represent technology artifacts that can be combined to form cloud technology architectures.
• Design patterns represent proven solutions to common problems.
• Cloud computing design patterns are (partially or entirely) applied by implementing different combinations of cloud computing mechanisms.
• Compound patterns are comprised of specific combinations of core (required) and extension (optional) member patterns.

“The best way to use patterns is to load your brain with them and then recognize places in your design and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse” (Freeman, Freeman, Sierra, & Bates, 2004).

Applying design patterns to the real world problems, requires knowledge and experience; it is the old combination of science and art. Like Albert Einstein said: “After a certain high level of technical skill is achieved, science and art tend to coalesce in esthetics, plasticity, and form. The greatest scientists are always artists as well”.

References

Arcitura Education. (n.d.). Cloud Patterns. Retrieved from Cloud Patterns: http://www.cloudpatterns.org/

Erl, T., Cope, R., & Naserpour, A. (2015). Cloud Computing Design Patterns. Prentice Hill.

Freeman, E., Freeman, E., Sierra, K., & Bates, B. (2004). Head First Design Patterns. O’Reilly.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2009). Design Patterns. Addison-Wesley.

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

“The z/TPF system is a high availability operating system designed to provide quick response times to high volumes of messages from large networks of terminals and workstations. A typical z/TPF system handles several hundred messages per second. A typical network varies from several hundred terminals and workstations to tens of thousands. The response time of the z/TPF system within a network is typically less than three seconds from the time the user sends a message to the time the user receives a response to that message. High availability is enhanced by the ability to quickly restart the system; restarting after a system failure takes between 30 seconds and two minutes. The z/TPF system is a high availability operating system designed to provide quick response times to high volumes of messages from large networks of terminals and workstations. A typical z/TPF system handles several hundred messages per second. A typical network varies from several hundred terminals and workstations to tens of thousands. The response time of the z/TPF system within a network is typically less than three seconds from the time the user sends a message to the time the user receives a response to that message. High availability is enhanced by the ability to quickly restart the system; restarting after a system failure takes between 30 seconds and two minutes” (IBM, n.d.).

Here is a diagram representing a z/TPF Processing Center (IBM, n.d.):

For many people the term z/TPF may seem unusual, but this mainframe operating system, originally called Transaction Processing Facility or simply TPF, has been active since the 70’s, and it had its origins during the 60’s. The z in z/TPF stands for z/Architecture, meaning 64-bit memory addressing capacity. It is 2**64 bytes of memory or  (18,446,744,073,709,551,616 bytes).

The following table compares and contrasts some of the Mainframe Operating Systems:

Legacy systems present many unique challenges and advantages, because of their inherent characteristics. They are monolithic, session based, the code usually has been designed to meet aged technologies and has become obsolete; their millions of lines of code are difficult to modify and/or maintain, but they are resilient, fast and still deliver acceptable to good services.

Many companies must decide how to deal with their legacy systems to improve their productivity, revenue and competitive advantage. They need to know how to deal with the “Beast”.

Migrate functionality to other platforms, refactor legacy code, cultural change for adopting agile technologies, isolate the mainframe to embrace new technologies; are some of the options to face and decide. Enterprise Architecture is the required big player to help.

References

IBM. (n.d.). Introduction to the z/TPF system. Retrieved from IBM Knowledge Center: http://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.13/gtpc3/ch1.html

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.

Governance is about establishing chains of responsibility, authority, and communications; empowering people’s decision making. It is also about establishing measurements, policy and control mechanisms to enable stakeholders carrying out their roles and responsibilities successfully.

“Governance is essentially about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization’s strategic objectives” (The Open Group, 2014).

The following are mentioned as necessary governance characteristics (The Open Group, 2014):

• Discipline
• Transparency
• Independence
• Accountability
• Responsibility
• Fairness

“IT governance is the decision rights and accountability framework for encouraging desirable behaviors in the use of IT. IT governance reflects broader corporate governance principles while focusing on the management and use of IT to achieve corporate performance goals” (Ross, Weill, & Robertson, 2006).

From the definitions presented above let’s narrow them to SOA governance by examining what the referenced sources have to say about its importance for a Service Oriented Architecture. All of them agree that governance is vital for a successful SOA practice as affirmed by (Erl, et al., 2015) “A critical success factor to achieving the goals of an SOA adoption project is ensuring that a formal and well-defined system is in place to support the regulated evolution of the services, solutions, and other resources and assets that comprise the planned SOA ecosystem. Without establishing such a system, there is a constant and ever-increasing risk that the IT enterprise will lose its alignment with the business domain to become progressively less effective and more burdensome”.

“SOA Governance is a globalized set of rules and practices designed to optimize an organization’s architecture and the services that are contained within that architecture” (Limaye, 2013).

(Limaye, 2013) Classifies SOA governance policies as:

• Design time: for building a service, provide rules for developers.
• Run time: for operating a service, can be enforced by a service management system.

SOA governance must mitigate risks and help to advance the organization strategy, priorities and goals. Like any other investment, SOA initiatives are expected to gain benefits greater than their costs. Those benefits are measured in terms of business outcomes reflecting the company’s objectives; SOA governance should ensure that SOA initiatives achieve targeted business outcomes (Erl, et al., 2015).

References

Erl, T., Gee, C., Kress, J., Maier, B., Normann, H., Raj, P., . . . Winterberg, T. (2015). Next Generation SOA. Prentice Hall .

Limaye, M. (2013, April). SOA Fundamentals & Governance. Denver.

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.

Service Oriented Architecture (SOA) is an approach to building business applications by representing solution logic as loosely coupled black-box components known as “services” (Limaye, 2013). These services must have well defined business objectives and perform discrete units of work. The provider and consumer of the service need to communicate by using same language, and the service has to be available and discoverable.

“SOA is not a luxury, the soup of the day, or a flash in the pan. It enables and is enabled by the biggest waves of technical innovation in the last three decades such as digitization, polymorphic objects, and the Internet. As a paradigm, SOA has the flexibility to transform innovations that are unknown today but will be known tomorrow into profit and growth” (Wik, 2016).

According to (Erl, et al., 2015) Gartner analyst Yefim V. Natis was the one who coined the term SOA in 1996, defining it as “a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations, and interface calls.”

Ideally SOA pretends to transform for better, poorly planned systems and fragile chains of dependency. The following service types mentioned by (Limaye, 2013) are very useful to understand the idea of services and how they fit into the SOA paradigm:

• Process Services
• Composite Services
• Atomic Services

SOA focuses on application reuse tied to business processes, advocates loose coupling to compose business objects without restricting who the consumer is.

“In a 2008 study, The Burton Group found that SOA projects in half of the 20 companies that took part in the study failed. On the other hand, some projects were “wildly successful”, significantly contributing to the company’s profile and profits. Another 30% were neither successful nor wholly failed. Failure was a tipping point where the company spent money and time with little return on investment (ROI). Technical success sometimes had no payoff. “Some users had executed nearly perfectly in terms of doing SOA on the IT side, but the initiative had not yielded increased agility, quicker time to market, or project savings because the business remained completely oblivious to the initiative”” (Wik, 2016).

Fifty percent of failure for SOA projects, compared to other similar IT efforts is high. What is needed? Framework, Governance, Management, Principles, Patterns? I may say all of them and more.

“SOA is at the apex of that trend of change over the last half century, from a low-level assembler of moving bit strings from one register to another register to high-level integration of moving services into clouds. “Give me a place to stand on,” the Greek mathematician Archimedes said, “and I will move the Earth.” SOA promises to move enterprises in a better direction. But if change is the changeless reality of our lives, where should we stand? Where is our security? Machines become obsolete because they cannot learn, but we can learn. Basic suitcase skills of reading, writing, analyzing, speaking, and interacting that let people excel in the Renaissance and the Industrial Revolution are the same skills that we need today and tomorrow. And, as we learn, we’ll find that seeking security in a firm or in wages or in a position is a mirage and that the only real security is that which lies within” (Wik, 2016).

Adopting SOA needs long-term commitment and a substantial reconsideration of the business, culture, technology and priorities of the organization. The next factors, are mentioned as fundamental and critical for achieving that success (Erl, et al., 2015):

• Teamwork
• Education
• Discipline
• Balanced Scope

“The concept of SOA provides an architectural style that is specifically intended to simplify the business and the interoperability of different parts of that business. By structuring capability as meaningful, granular services as opposed to opaque, silo’ed business units, it becomes possible to quickly identify functional capabilities of an organization, avoid duplicating similar capabilities across the organization and quickly assemble new capabilities.” (The Open Group, 2014)

Enterprise Architecture is vital to help an organization becoming service-oriented, by linking stakeholders together ensuring awareness of their appropriate context and helping to meet the needs of the stakeholder’s community.

References

Erl, T. (n.d.). Service-Oriented Architecture. 2005: Prentice Hall.

Erl, T., Gee, C., Kress, J., Maier, B., Normann, H., Raj, P., . . . Winterberg, T. (2015). Next Generation SOA. Prentice Hall .

Limaye, M. (2013, April). SOA Fundamentals & Governance. Denver.

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

Wik, P. (2016). Service-Oriented Architecture. Blue Kitten.

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.