The security Architecture

Post No.1- Enterprise-wide security

Enterprise Architecture programs allow enterprises to bridge the gap between strategy and operation via the effective deployment of technology. These technology components can be subject to threats that target business and technology operating environments. Therefore it is absolutely important to ensure that security & privacy controls are taken into consideration in the design of all EA components in an integrated manner.

On the surface, many organizations seem to look security conscious. An organization can be ISO 27k certified, with security policies and procedures that are developed and published and an information security management structure which directs, monitors and controls the implementation of information security, but yet does not build security into their architectures. Many organization have their security controls established only at the solution deployment and technology level.  Even when regular risks assessments take place, most of the remediation actions are not realized if it does not fall under the technology teams’ responsibilities.

Aligning Security Architecture and Enterprise Architecture, or even better incorporating it within the different layers of the enterprise information technology stack (Goals and objectives, Organizational structure and Business processes, Data and Technology infrastructure and Systems and Applications) provides a strategic insight into the security and privacy program.  Thanks to the holistic approach of the Enterprise Architecture, security and privacy solutions and processes will be well aligned with business goals, architectural decisions and adopted technology standards and capabilities; hence, making them more effective.

In order to develop the security architecture, all the enterprise artifacts should be assessed for possible sources of threats and to determine the proper level of protection needed. The architecture should address the Information design and assurance issues which affects business process. Authentication and access issues should as well be addressed. All physical protection aspects should be considered in the architecture such as server rooms, building security and telecommunications means. Moreover standard operating procedures should be developed to describe the course of action needed in the occurrence of any possible security incident. Another element of the security architecture is Disaster recovery and continuity of operations. The area of personnel security should be an integral part of the security architecture: staff verification, awareness and procedure training should be thoroughly covered.

For more information on the topic, visit: https://www.isss.ch/fileadmin/publ/agsa/Security_Architecture.pdf

https://psu.instructure.com/courses/1829637/files/80463859/download?wrap=1

You may also refer to chapter 11 of Scott A. Bernard book “An Introduction to Enterprise Architecture: Third Edition”

Post No.2- Data masking to protect sensitive data

Certain data require a higher level of protection against unwarranted disclosure due to its sensitivity. Access to sensitive data should be safeguarded. Protection of sensitive data may be required for legal or ethical reasons, for issues pertaining to personal privacy, or for proprietary considerations.

The following data types needs to be secured throughout all its forms whether structured or unstructured:

•        Financial Data such as bank account information
•        Medical Data
•        Identity related data such as Driver’s License Numbers and Social Security Numbers that can be used to commit fraud and identity theft.
•        Intellectual Property Data such as product development information
•        Human Resources Data
•        Communications Data such as email access data and telephone records

One of the risks of exposing these sensitive data comes when production data is copied to development and test environments to allow system administrators and developers to test upgrades, patches and fixes which compromise critical and confidential information and put it under the wrong hands.

Data masking is a method that can be deployed to accommodate data privacy laws and control access to sensitive information in a non-production environment. It involves creating a structurally similar but inauthentic version of an organization's sensitive data before transporting it to test or development environments. Data masking is in general a trade-off between security and reproducibility.

Implementing Data Masking requires enterprises to carry the following high level steps:

•        Identifying and cataloging sensitive across the enterprise
•        Identify the masking algorithms that represent the optimal techniques to replace the original sensitive data
•        Conduct masking trials to verify the masking algorithm, this is usually carried by security architects and DBAs.
•        Test that the application is performing successfully after the masking process has completed.

It is worth to note that several Sophisticated Masking Techniques exist such as: Condition-based masking, Compound masking and Deterministic masking.

Security architects and DBAs are encouraged to use over-the-shelf masking packages that gives them the flexibility to build their masking routines.

Here you can find an Oracle White Paper on Data Masking best practices:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjXzoaw9OPSAhUJI8AKHRuIBHsQFggjMAE&url=http%3A%2F%2Fwww.oracle.com%2Fus%2Fproducts%2Fdatabase%2Fdata-masking-best-practices-161213.pdf&usg=AFQjCNFQ4j-5_hgWmZ9fYgwyS46jdEL0HA&sig2=dS2uVRB4eprrTBJxNtNm0g

Post No.3- Forrester's Zero Trust Model

As mentioned in a previous blog, data is now seen as a strategic asset that can be sold, exchanged and even stolen by cybercriminals. Forrester has developed its Zero Trust model to help security architects to promptly detect and respond to security incidents related to data no matter where it resides in the digital business ecosystem.

Enterprises are already starting to embrace digital business practices in order to achieve the differentiation factor. Internet-of-things (IoT) components, cloud computing and mobile point of sale solutions are some the technologies exploited by today’s business to satisfy and impress the customers. Security architects are challenged to protect data in today's new Business Models using their traditional security approaches, some of these challenges are:

•        Cyber-criminals are no longer individuals who are targeting direct financial gains using traditional typical hacking techniques. They are now organization sponsored, well-funded, skilled and specialized resources who use sophisticated attacking techniques to sabotage enterprises, gain competitive advantage or steal data to monetize later
•        Protection is no longer limited to the corporate network. Sensitive corporate data how travels to a wider ecosystem reaching partners and customers anywhere
•        Breach detection technologies used by many of the enterprises, today lacks advanced intelligence and analytics to anticipate, prevent, and mitigate threats

Forrester's Zero Trust Model of information security encourages security architects to eliminate the idea of a trusted internal network and an untrusted external network and fully embrace these concepts:

•        Verify and secure all resources and data assets regardless of location
•        Limit and strictly enforce access control across all user populations, devices/channels, and hosting models
•        Log and inspect all traffic, both internal and external
•        Never assumes trust; "trust" is continuously assessed though a risk-based analysis of all available information
•        Marshal the functions of many security domains, such as network, identity, and application, in a unified approach to data protection

Applying Zero Trust concepts will help enterprises to:

•        Safeguard the enterprise intellectual property
•        Turn data security and privacy into an opportunity to retain, reinforce customer trust
•        Reduce the frequency of breaches and limit the erosion of customer confidence
•        Shield the enterprise’s reputation

Adopting Forrester Zero Trust model is a four steps process that summarized in the below figure.

For more information on this model can be found here: https://www.forrester.com/report/Defend+Your+Digital+Business+From+Cyberattacks+Using+Forresters+Zero+Trust+Model/-/E-RES61555#

The Enterprise Technology Architecture

Post No.1- Setting up an enterprise technology architecture

According to Gartner: “The enterprise technology architecture (ETA) viewpoint defines reusable standards, guidelines, individual parts and configurations that are technology-related (technical domains). ETA defines how these should be reused to provide infrastructure services via technical domains.”

While this might seem as pure technical choices, it is critical to note out it is just one layer of a stack, therefore, any design option should be supported and justified by requirements driven from the other layers: business, data, applications and security.

The primary objectives of developing an enterprise technology architecture are:

•       To  effectively  remove  hardware  obsolescence  or  vendor  dependency  as  a  requirement
•       To  periodically  review  the  systems  in  support  of  the  organization’ needs
•       To  ensure  that  the  rapidly  changing  external  and  environmental  trends  are  enforced  to  significantly change the business and technical environments within organizations

Developing the architectural products of an Enterprise’s ETA is not an easy task. It is a process that usually starts by finding out where the business is headed and how that will affect your technical architecture. Business  strategy  is  the  primary  driver  for  the  development  and  implementation  of  the  technical  architecture. The structure of the organization, the business model and the geographical locations of the offices are some of the very basic inputs that dictate the model of your ETA.

The extracted requirements are used as an input to  develop  the  architectural  products,  which are a  set  of  models  and  views  of  the  organization.  Requirements such as business scalability, Latest technology and environmental trends and competitive advantage are all considered and developed into an architectural context.

Once the architecture is clear, Technical architecture requirements are then derived from the architectural requirements. These technical requirements will guide the engineering   of   the   organization’s   information   systems   and   technology   infrastructure.  Technical domains are then to be defined into Domain-level technical architectures along with the domain-level principles that govern the selection and use of the technologies in each domain including product and configuration standards.

The ETA can be part of a complete EA initiative or not. In both cases its implementation involves a gap analysis exercise, based on which a migration plan is developed and implementation projects are defined.

The process described in this post is taken from “A FRAMEWORK FOR DEVELOPING AND IMPLEMENTING THE ENTERPRISE TECHNICAL ARCHITECTURE” a paper by Tiko Iyamu, Tshwane University of Technology

https://www.google.ae/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiQm5v99q7SAhUEbxQKHYeCAUsQFggYMAA&url=http%3A%2F%2Fgesj.internet-academy.org.ge%2Fdownload.php%3Fid%3D1763.pdf%26t%3D1&usg=AFQjCNGpW-34yW_kn2ZXRZoqen6Grjh6EQ

Post No.2- Measuring the value of the ETA

Once you have an ETA in place, it is wise to define/develop a set of metrics to measure the value of enterprise technical architecture. This will help the ETA program to gain the trust of the executive team and secure the future investments. In addition to this, it will act as a source of input in the technology planning process.

To satisfy Business stakeholders, IT leaders should define Enterprise Technical Architecture Metrics that is mapped to Business Metrics, an example would how a new technology has increased the productivity of the customer services department. This metrics relates well the business people and allow them to see the technology as a business enabler function.

Some of the metrics should be pertaining to technology standards, and how much it was followed in different projects. These metrics will help us measure the compliance in order to ensure that we reap the benefits of lower total costs of ownership and costs to change. Examples of these standards are: The number of designs that are 100% compliant, the number of projects actually checked for compliance (vs. all projects), Time taken to design and the Year-over-year improvement across many projects.

Other metrics can measure the degree and value of reuse. The number of technical patterns reused, the number of components reused and the number of technical serviced reused, are all examples of metrics that shed the light on the value of the ETA.

In general, metrics that demonstrate costs savings should be tracked and reflected to the business. Without such metrics, business will continue to see technology as a cost center and fails to see beyond this.

For more in this topic please read the Gartner article “Develop Enterprise Technical Architecture Metrics to Demonstrate Enterprise Architecture Value” at https://www.gartner.com/document/1330249

Post No.3- Auditing the ETA

ETA is often perceived as a mature field, yet many organizations fail to commit to many aspects of it, in particularly the documentation.

Last semester, I was asked by a colleague to review the ETA of his organization. I listed down some questions that resembles my understanding of what to expect in an ETA.

First and Foremost, I found out that the mission, vision, goals and objectives of the enterprise are not part of the architectural sets. Although some of the architectural decisions were backed with business requirements, not all of the technical requirements could be traced back to business drivers in the documents. I had to ask them for it to get the answer, verbally.

In other areas, they had great documentation. Conceptual, logical and physical models were there. Inter-operability requirements were well demonstrated along with functional and non-functional requirements. In addition to these, various products standards and configuration standards were stated in the documents.

They however lacked in to major areas:

•        They did not have metrics of any sort
•       No clear governance on how this ETA is maintained. They should have considered defining how a new technology is introduced and the decision process behind it

Overall, I felt their ETA was so complex and not well acquainted to the business and its future plans.

Posts in Data Architecture

Post No.1- Major Components of Data Architectures

Now more than ever, organization has started to see data as a strategic asset that can be sold and exchanged. In the near future, the digital revolution with concepts such as the Internet of Things (IoT) will push companies to collect, and analyze vast volumes of data and therefore, architect in a way that adds to its business value.

The enterprise data architecture should be defined and modeled at the three levels of abstractions:

•      Conceptual level to describe the high level business perspective of the data entities, how they deliver value and how they will be used. At this level data can be seen as Business information conceptual entities whether it is structured data, enterprise contents or taxonomies.
•      A logical level that describes in much detailed modeling how data is represented and interrelated. At this level Schemas are defined and data are mapped to applications or taxonomies.
•        A Physical or implementation level modeling that reflects the builder perspective such as Physical data stores and repositories for both structured data and enterprise wide information contents.

Without a proper data architecture, organizations won’t be able to drive strategic change. Therefore, it is very important not to see data architecting as a technical job. Old data models are no longer sufficient to fulfill business demands. Experts suggest the following eight components to go into the building of a modern data architecture:

•         Engage business users in identifying the most valuable types of data
•         Make data governance a first priority
•          Ensure your data architecture is not developed around a specific technology.
•          Develop a real-time foundation to support analysis and movement
•          Build security within the foundation
•          Develop a master data management strategy
•          Position data as a service to enable information to be pulled from multiple sources.
•          Offer self-service environments to allow business users to build their own queries.

The link below contains useful information on the topic:

http://www.dbta.com/Editorial/Think-About-It/8-Steps-to-Building-a-Modern-Data-Architecture-101417.aspx

Post No.2- Data Architecture Governance

Data architectures does not involve only designing data models but it includes the rules, policies, and standards that govern how data is used, stored, managed and integrated within an organization.

Gartner defines data governance as “the specification of decision rights and an accountability framework to encourage desirable behavior in the valuation, creation, storage, use, archiving and deletion of information. It includes the processes, roles, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals. “

Data governance addresses many pain areas that face organizations today. It can improve the organization ability to deploy data for external use. It can also improve Data error remediation process and thus enhance data quality by addressing root causes of data issues.

A data governance document in an organization typically includes the following sections: Roles & Organizations, Data Strategy, Policies & Standards, Compliance, Issue Management, Projects & Services, Data Asset Valuation and Communication.

The emerging digital business that deal with vast amount of data requires data governance to cover areas such as: Big Data, Mobile Data Platforms, Social media, Data Demand Management and Regulatory Coordination.

Typical roles in Data governance are: Steering Committee, Data Governance Sponsor, Data Governance Head, Data owners and Data Stewards.

Data architects may recommend enabling technologies to support data governance and stewardship workflows such as Data profiling, Data discovery, and Business glossary and data lineage.

For more on this interesting topic, please pay a visit to this link:

https://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2014/Implementing%20a%20Data%20Governance%20Program%20-%20Chalker%202014.pdf

Post No.3- Data Architecture and Informational Architecture

I have recently read a blog whose author is among a team that work to clean up the Wikipedia pages dealing with Enterprise Architecture. The author was discussing how his team found out two separate pages in Wikipedia one dedicated for Information architecture and the other for Data Architecture. The author made a simple survey to determine whether they should keep Data Architecture and Informational Architecture as two distinct terms in Wikipedia or as a single term, and in this case, which one should they keep Data Architecture or Informational Architecture.

The results of the 55 respondents was split even. Most of those who claimed that it is one field, favored Information Architecture over Data Architecture.

I went through different articles and blogs over the internet that have different interesting viewpoint on the topic. Some would argue that Information is data within context, therefore data architecture is a subset of Information architecture. Others see Data architecture as the bigger picture whereas how information is modeled as being part of it.

My personal viewpoint is that it depends on the context on which the term is used. In different levels of abstraction for instance the terms can be Data or Information. To Business Intelligence experts working to extract data from its sources it is no doubt data, whereas it is information for those working on Enterprise Content management system for instance. In general, Data architecture represent the technical view and Information architecture represent the business view.

I certainly go with the term data when I am setting architectural principles, stewardship requirements and other governance requirements. However, regardless of any debates on the topic, the most important thing is that Data and Information architects should know how to build their models, methods, standards and governance in support of the business and its drivers.

Here is the link of the blog and the survey results:

https://blogs.msdn.microsoft.com/nickmalik/2014/11/21/do-you-perform-information-architecture-or-a-data-architecture/

See you the in the next blog!

Posts in Application Architecture

Post No.1- Design Requirements in Application Architectures

Gartner defines the discipline of application architecture as follows “Application architecture combines a core set of solution architecture design artifacts with architecture and design best practices to effectively guide application construction, deployment, ongoing performance and continued evolution of the application portfolio. A disciplined approach to application architecture enables real business value, enhances the organization's leverage, facilitates user adoption, drives down the total cost of application ownership and minimizes the risk of failure”

This definition means that the application architect’s job is not limited to mapping the business functions to application components but it extends to cover other non-functional requirements such as interoperability, performance, scalability and security.

Interoperability is the ability of an application component to work with other components without special effort. The application architect should design the components in such a way that they can seamlessly communicate, exchange data, and use the information that has been exchanged as needed. The application architect should study and identify the required degree of interoperability and incorporate it in his architecture.

To design an application architecture that has a high performance and scalability, the application architect need to consider the following these design principles: Ensure that services components are defined at the appropriate level of detail to increase your ability to encapsulate change, Put the processing closer to the resources it needs (processes that require heavy data interactions should be kept at the backend), Process independent tasks concurrently, Pool shared resources to improve scalability by sharing a limited number of resources among a much larger number of clients., etc. For more design principles use this link https://msdn.microsoft.com/en-us/library/ff647801.aspx

The application architecture should be carefully reviewed by a security architect to identify and eliminate any security flaws at an early stage. I will be posting a dedicated topic on security architecture on or before March 20^th.

These were few of some of the nonfunctional requirements that should be considered in an application architecture, for more in the topic please refer to this Gartner article https://psu.instructure.com/courses/1829637/files/80463989/download?wrap=1

Post No.2- Service Oriented Architecture in a glance

You can’t be talking about application architecture without mentioning Service oriented Architecture (SOA). Nowadays, application architects realize the several benefits of adopting SOA principles in their designs; improved maintainability, lower costs and Increased agility and productivity to name a few.

SOA is a way of architecting the application into the form of services. That is a group of discrete software chunks that have simple, well defined interfaces and are able to interact with each other with loose coupling.  A service can play any of these roles; Service provider and service customer.  The whole concept is supposed to help organizations build services libraries that can in turn speed business results.

Nevertheless, it is not an easy task to adopt SOA in your organization. It requires tremendous commitment and support from the CIO and IT leadership. An application architecture governance organization should be in place. This organization should ensure that SOA culture is well received by application and technology architects. This teams would probably require education and coaching on how to design, develop, reuse and deploy these services. The technical team should be ready to modernize their infrastructure to support the team. All of this is easier said than be implemented and it requires a structured approach.

Gartner recommends that organizations considering SOA to follow this roadmap:

•        Strategize and Plan: Draft a charter to gain agreement on the vision for the initiative, in alignment with business goals
•     Develop Governance: Establish an optimal process for making decisions and assigning decision rights
•     Drive Change Management: Set up a system to communicate and socialize ideas via multiple channels. Get buy-in from stakeholders at all levels
•     Execute: Optimally operate the initiative in accordance with business goals
•     Measure and Improve: Measure how the initiative has affected business outcomes

For more on this, please visit this page https://www.gartner.com/doc/2513915/soa-application-architecture-key-initiative

Post No.3- The Application Architect vs. The Solution Architect

This is a short post is an attempt that intends to answer this question: We do not have an EA program in our organization, but we do have a solution architect; can we call him an application architect?

I believe that there is no standard answer to this question, it depends on your organization and back ground. What I can say in general that the solution architect usually interact with subject matter experts to ensure that they have an optimized solution that cater for budget, time and business requirements. The application architect has a different perspective, he is usually a role within an enterprise architecture practices. He is more concerned of how the complete application portfolio is architected to maximize reuse, performance along with other functional non-functional requirements.

The Federation of Enterprise Architecture Professional Organizations (FEAPO) ‘guide in careers in enterprise architecture states that “the Solution Architect tends to focus on a particular, tangible, often tactical, problem. The Solution Architect will often have a single, clear business leader whose metrics are driving the need for change.” The guide also states that the Application architect is a role in the stack of roles that define the enterprise architect; all of which are strategic in nature.

For more information, you may look at:

http://feapo.org/Collaboration/sites/default/files/Guide%20to%20Careers%20in%20Enterprise%20Architecture%20-%20v0.21.docx

http://www.enterprisearchitecturecenter.com/enterprise-architecture-strategy/solution-architecture-and-application-architecture

That’s all about application architecture, see you soon!

                         

About the Enterprise Information Technology Stack

Post No. 1- The Technology Stack and future topics

I will continue to share with you my thoughts and learnings on the domain of enterprise architecture. What have been published so far has always discussed enterprise architecture from the viewpoint of the business; which is great, as business the true driver of EA initiatives .In the coming few months my blogs will cover topics in enterprise architecture from view angle of technology leaders.

The Open Group’s Allen Brown once said “The goal of enterprise architecture is boundary-less information flow, where all systems, IT and non IT, interoperate”. Whether you agree or not with how he expressed the goal of EA, the saying puts it simply: EA involves IT and non IT domains and that’s business.

Aside from the business part of EA, which I have covered heavily in my previous posts, there are several layers that collectively describe what we call the Enterprise Information Technology Stack. These layers are:

• ·      Applications
• ·       Data or Information
• ·       Infrastructure
• ·       And the cross cutting thread: Security

Gartner defines the Enterprise Technology architecture (ETA) viewpoint as “the reusable standards, guidelines, individual parts and configurations that are technology-related”. Across all the stack layers standards and guidelines should be supporting not only interoperability but principles, objectives and requirements set by the business layer of EA.

The terminology stack itself is very technology specific. Often used by and to CIOs and CTOs and technology experts to describe a visual representation of the interaction between layers. The understanding of how the stack is composed in terms of interactions and boundaries allows them to develop capabilities as well as managing change by governing the impact of the new capabilities.

I will continue to share with you my thoughts and learnings on the domain of enterprise architecture. In the coming few months my blogs will cover topics in enterprise architecture from view angle of technology leaders. It is however important to note that my intention won’t be on bringing down topics of mere technical nature. But rather, the guidelines, principles, standards and components that represent the technology related domains, such as applications, data, infrastructure, in the overall enterprise architecture. Security related posts, which is a critical crosscutting thread in EA, will find its way to this blog.

Post No. 2- The application stack or the software services network

As part of my readings this week about technology stack layers, I came across a Forbes tech page article by Larry Hawes, titled “Enterprise software Architecture: a Network of Services, Not a Layered Stack”. It has been the source of this post.

If we would like to focus on the application layer of the enterprise technology stack; how would we like to visualize it: as a stack or as a network of services?

The term application stack gives the indication of hierarchical interaction, where every layer can only interact with the layers above and beneath it. This representation does not go well with the guidelines and principles that are set by any decent EA program that calls for scalability, performance and flexibility.

Software vendors are no longer adopting these traditional stacked architecture. Their architectures can be described as a network of functionalities and services. Multiple services can be combined to form an application for a specific purpose. With this designs application developers can build solutions that allows enterprise to reach and connect with their larger ecosystem, by pulling data from on service node to be used by several internal and external service nodes.

The dynamic nature of this network architecture will be of a profound value to the business. It will allow business to be able to face changes, adopt technology advances and even try and embrace new business models without worrying to limited by the limitations of the traditional hierarchical application architecture.

Post No. 3- Skills required by every stack layer

Someone is ought to carry the architectural work.  But what is this talent that should have a good level of expertise in every layer of the stack, along with in-depth understanding of the business!!!

Fortunately, FEAPO (Federation of Enterprise Architectural Professional Organizations) developed a framework that can be used for identifying competencies and critical skilled required in an EA team.

No surprise, the framework is based on the BAIT+S (Business, application and information, technology and security). Competencies are identified for each of the following roles:

• ·       Business Architect : to answer why the change is needed
• ·       Information architect : to answer how information moves
• ·       Application Services Architect: to answer how systems deliver services
• ·       Tech Architect : how technology support them all
• ·       Security Architect : for the management of secure data

An article by Gartner presented two different thoughts: An Enterprise architect as a higher level role and not a maturing role, and that business’s, information, technology and solution architect roles have a specific expertise that is measurable.

To summaries, thanks to FEAPO and Gartner, we do now have guidelines that organizations can adhere to when establishing and progressing an EA career path. Internal staff can be prepared to take such roles, or if organizations wishes, selection criteria can be tailored to hire from outside.

Fellow Penn Staters interested in this post can contact me to give them a copy of a paper which my group have prepared on EA careers as part of a course requirement.

EA in the innovation era.

Now more than ever, organizations are embracing EA practices as they know it is the true answer to today’s business agility and technology disruptions. Large organizations are busy developing their EA capabilities in a manner that gives them an advantage over their competitors.

Digital business trends have created new business designs. Enterprises that are sticking to their traditional EA practices will not be able to cope in this era of digital transformation. The skillset required in this era is no longer IT focused. Organizations need to recruit and develop EA caliber that is business outcome focused and very responsive to technology innovation opportunities.

According to Gartner, world-class EA practices that can stand-up to this challenges have a wide range of stakeholders involved in the EA program. Their teams usually have a deep understanding of the strategy and are equipped with a variety of advanced team resources that enable problem solving skills.  In addition, these organizations have well-structured enterprise architecture governance that defines how the EA program is maintained and how it relates to other enterprise-wide process such as capital planning. Moreover, they do a have solid EA measurement program that is well integrated within the architectural process.

Yet, this world class EA practices needs to improve its ability to identify and understand the business economic and financial factors that is impacted by innovation. The fact that innovations are not tested technologies, requires that these organizations conduct emerging technology evaluation and determine the opportunities that can be sought to achieve certain business outcomes.

This means that the future will call for super enterprise architects who do not use the traditional ways of EA to support decision making. These super Enterprise architects will not emerge out of nowhere. In fact EA institutions needs to start preparing and developing them.

Good and Bad practices of transitioning to the future State

Lately, I was among a group of enterprise architects and IT professionals who shared their experiences and thoughts on how their organizations transition from a current state to a desired future state, in particular we discussed the use of road-maps to help the enterprise visualize the transition. Although I have blogged twice about EA road-maps, I decided to share this interesting discussion and my thoughts out of it.

It surprised me that many of them felt that the road-maps developed in their organizations are “too dense with technical information”. Loads of technical details are included such as Application Middle-ware Services, Data Services, Network Services, Network-based Services, Platform Services, Development Services, and Security Services making them rather look as technical deployment plans. Identified initiatives are not presented in a way that shows how they are related to strategy and dependent on each other. In other words, it is very difficult to get the information you need out of them. I can see that these organization had fallen into one of the worst EA practices identified by Gartner which is: confusing technology architecture with enterprise architecture.

Some professionals mentioned that their organizations do not use road-maps to guide change efforts. In these organizations, changes are identified in a reactive manner. Changes are either triggered by stakeholders or internal and external events through emails, process workflows and town hall meetings.  Well, I am confident that these organizations suffer from poor coordination and a lack of a common ground on how the enterprise should move towards its future directions. Therefore, It can be said that they do not really have an EA program in place.

Many professional stated that their organizations use graphical high level road-maps to illustrate the sequence of capabilities that need to be obtained to reach the desired future state.  Their road-maps are updated on a periodic basis to reflect the timelines and scope of initiatives that will affect the organization. According to them, these road-maps were excellent communication tools that brought the attention of even the non-executive staff.

One of the enterprise architects explained how their business outcome based enterprise architecture practice leveraged the use of road-maps to communicate their transition to the target architecture in the most effective way, by listing the outcomes and the initiatives along with disruptors and risks. This has allowed them to show what would be delivered and how these outcomes would address the disruptors and risks. I believe that this approach has allowed stakeholders outside of the enterprise architecture team to easily understand the goals of the enterprise architecture program.

There is no doubt that a simple, clear graphical EA road-maps can allow the organization to coordinate and communicate change efforts, as long as this road-map is kept current.

See you in week 15 !