Making use of Emerging Technology Trends

Post No.1- Emerging technologies Themes

The previous blog focused on how developing an EA practice that is business-outcome based is a practical approach in today’s business environment. It allows business to make quick wins by capitalizing on relevant business disruptions.

Technology is growing at an exponential rate. Gartner’s Top 10 Strategic Technology Trends for 2017 shows us that we are heading towards a radical, long-term (2020 to 2025) evolution of the user experience for both customers and employees. EA experts and technology innovation leaders must support their organizations to positively respond to the disruptive technology trends to stay competitive and differentiate themselves.

Gartner suggests that the top 10 strategic technology trends fall under these three themes:

•        The intelligent theme
•        The digital theme
•        The mesh theme

The intelligent theme features trends like Artificial Intelligence (AI), machine learning, intelligent apps and intelligent things. AI and machine learning can be useful in scenarios involving productivity and accuracy. Possible AI applications in banking are Enhanced Customer Personalization and Fraud Detection. The retail industry can use AI to build propensity-to-buy models. Intelligent apps are rapidly maturing such as virtual personal assistants, virtual customer assistants and virtual financial advisers. The world's largest companies will exploit intelligent apps along with big data and analytical tools to refine their offerings and improve their customer experience. Business is also expected to continue to seek opportunities to use robotics in automating their current manual tasks.

The digital theme revolves around blending the digital and physical worlds. Some of the growing trends in this theme is Virtual Reality and Augmented Reality.  These are used by organizations to create a simulated environment that can be used to enhance the design and manufacturing processes. Digital Twins-which are dynamic software models of a physical systems- are used by the business to study systems, their applications can vary from high-value assets optimization to enhanced products development. Blockchain technologies, such as Bitcoin, facilitates secure online transactions across many computers in such a way that the registered transactions cannot be altered retroactively. It has numerous possible business use cases that can radically transform economic interactions once it get properly regulated.

The mesh theme is about exploiting connections between an expanding set of people and businesses, as well as devices, content and services, to deliver digital business outcomes. New input/output mechanisms will emerge using audio, video, touch, taste, smell and other sensory channels, such as radar, which will enable people to communicate with systems, and systems to communicate with people. This can open the door to many new digital business opportunities.  Platforms such as the IoT platform, Information system platform, Customer experience platform, Analytics and intelligence platform and Business ecosystem platform can be used together to provide an interoperable set of services that can be brought together to create applications, apps and services.

These technological trends are expected to change the business world entirely, therefore organizations must carefully evaluate which one to track and adopt.

You can find Gartner’s Top 10 Strategic Technology Trends for 2017 in this link: https://www.gartner.com/document/3471559?ref=solrAll&refval=183575405&qid=2fec14f62d1620bf52c1d3

Post No.2- Assessing Key Technological Trends

In the previous post, we found out that there are too many disturbing technologies that will affect the business world. This will leave EA experts and technology leaders challenged to determine which technology trends might have the greatest impact on their organizations business models.

Gartner suggests that EA professionals should start by assessing the potential Impact of a trend specifically on four key areas:

•        The Human Experience: Analyze the needs, wants, desires and pain of individuals, and the different customer types and their interactions with the technology.
•        The Business Experience: Study which initiatives based on the trend affect business operations. Are there any opportunities to reduce expenses or improve operational efficiency?
•        The IT Experience: Determine if the current capabilities are ready and mature enough to take advantage of upcoming technology trends.
•        The Technology Market Experience: Study the opportunities and threats that is brought by the trend to the technology market.

Then EA professionals should evaluate the degree of maturity of the trend, understand its position as an emerging, growth or mainstream trend. The maturity of the trend determines the way on which the organization can respond to it. Trends that are rapidly changing and evolving require more focus because its underlying technology is changing. Trends that are offering practical solutions to help organizations take advantage of, should be considered.

The trend’s market dynamic should also be evaluated by EA professionals, questions such as what is the level of market interest the degree to which the trend is incorporated in strategical and tactical plans of other organizations, should be asked. Some risk taking organizations decide to start experimenting with a technology whenever potential use cases are validated. Others prefer to wait and watch how the trend is exploited by other business to learn from them.

Now that EA professionals are equipped with the all the needed information about a specific trend, they should start to study how this trend is relevant to their enterprise context, mainly in terms of its business model and strategy.  They may recommend to the management that they should ignore the trend, monitor it whether periodically, actively or aggressively, or they may recommend adopting it.

From there, business outcomes that support the approved list of trends should be identified and defined, accompanied with a set of business scenarios that the trend could address. Opportunities and risks should then be evaluated before finally creating a transformation roadmap.

You can find more about Gartner’s approach to identify the technology trends that organizations need to track in this link:

https://www.gartner.com/document/3649618?ref=solrAll&refval=183575405&qid=2fec14f62d1620bf52c1d3

Post No.3- Designing Innovation Centers

In this era of innovation, where business has either “to differentiate or die”, many organizations are establishing innovation centers to deliver both creative exploration and business value. In this post, I am highlighting the seven best practices to create an innovation center as suggested by Gartner.

The first recommended practice is to determine the goals for the innovation center. These goals are usually revolving around the innovation projects that the center will target, the relationships that the center will pursue with institutions and other hubs and the use of the center physical space.

Another recommended practice is to select the center’s location based on access to talent and ecosystems. However, organizations should beware of failing to retain its key talent in a highly competitive geography. At the same time, they should make the trade-off between keeping the center close to strategic decision-making power and away from the rest of the organization that can affect the progress and the culture of the center.

Gartner also suggests that organizations should ensure the center’s funding, staffing and resources match the ambitions. The nature of partnerships that the center should seek, the number of the staff and their talents range should all be carefully determined.  

Centers should also focus programs on areas of opportunity and growth that require central attention such as high-benefit, high-risk opportunities, emerging topics that benefit multiple areas of the organization and new processes and cultural norms.

An important best practice is to design the center’s activities to span the innovation process. The center’s scope should not be limited to proving out the idea or technology but they should go all the way until it is transferred to the line of business.

The sixth best practice involves clarifying relationships to internal and external partners. Internal relationships includes handing over ideas to other parts of the business, solve challenging problems requested by business executives and acting as a center of excellence. External relationships include partnerships with universities, investment companies, incubators, startups, government and industry bodies, while keeping a close eye on intellectual property issues.

The last best practice is to develop metrics to measure qualitative as well as quantitative outcomes for creativity and business value. Gartner recommends using a mix of objective and subjective metrics beyond the ROI because the results of innovation are often hard to know in advance.

The link below is an article that includes more information on the topic, it also includes links to some useful case studies:

https://www.gartner.com/document/3186721?ref=solrAll&refval=183573543&qid=eea584809fd813e481d54d

             

Posts on Business Architecture

Post No.1- The business architecture

Business architecture is an integral part of enterprise architecture. An EA without business architecture is no more than IT architecture.

Business architecture plays a great role in translating the corporate vision into actionable objectives.  It is with business architecture that we visualize the end-state of the organization while keeping all the business units aligned and focused on the strategy in such a way that improves decision making and increases operational efficiency to deliver significant business value outcomes.

In a previous blog, I have posted about how Gartner recommends that the chief enterprise architect should work with the business to build a common understanding of the enterprise context. The enterprise context will the perfect basis on which EA principles that can be used as a decision making criteria by business and IT.

Gartner stresses that the business context is not one of the viewpoints of the enterprise architecture, it should never be treated as the business architecture. It rather overlays and informs all of the EA viewpoints to ensure an effective strategic integration and a focused direction of effort.

In fact, Gartner recommends that the entire EA team (business, Information, technology and security architects) should be part of developing the enterprise context to help improving the support for the business strategy avoid creating a "tiered" architecture.

Once the enterprise context is defined, models that describe the future-state EA vision should be developed along with the long-term targets for change and how to move toward these target states successfully. The future architecture should describe all the enterprise dimensions: people, financials, organizations and processes.

A current state model is then developed to be as a baseline from which migration plans can be planned and executed.

Please refer to the following links for more information on the topic:

http://myeathoughts.blogspot.com/2016/09/understand-your-enterprise-context.html

http://myeathoughts.blogspot.com/2016/11/translating-strategy.html

http://myeathoughts.blogspot.com/2016/10/business-focused-business-architecture.html

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

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

Post No.2- Business-outcome business architecture

There is no better way to demonstrate the value of Business Architecture, than focusing on the metrics that matter most to the enterprise senior executive team.

Many EA programs had failed because the EA team was very much consumed with enterprise architecture activities and practices and failed to relate to the business and to where it is heading and to show a line of sight between business vision and change that the whole enterprise can use as a guidance.

As a business change discipline, EA‘s the long-term value and impact can only be assessed through the business outcomes that were successfully achieved for the benefit of the enterprise.

Recently, many organizations realized that they need to move from their traditional EA program, to an EA program that is business outcome focused. To ensure their business architecture is mapped to the enterprise business outcomes, the following aspects are considered:      

• The relative focus on strategic business initiatives
• The capabilities of EA, given the business strategy, future vision and maturity
• The business outcome and value statements that reflect the business's direction and strategy
• Potential metrics (target results) that are derived from business key performance indicators

The figure below from Gartner demonstrates how EA can be aligned to the strategic business initiatives:

Gartner recommends that the EA team should plan their business outcome-focused architecture into iterations. Each iteration should have its set of metrics defined upfront before starting any architectural work, to ensure that EA measurement is built within the architectural process. The quick value realization will boost the support of the EA program and allows the enterprise to better cope with today dynamic business environment.

The following links includes more information on the topic:

https://www.gartner.com/document/code/247593?ref=grbody&refval=3184620

https://www.gartner.com/document/2863320?ref=solrResearch&refval=182646710&qid=ed484b2dacffe81a0c26beed6e990b46

https://www.gartner.com/document/3642517?ref=solrResearch&refval=182647328&qid=1d64e80790f7aa019270aeec97980dca

Post No.3- BA and Digital Business

We are almost living a digital world, the advancements of the technology and the number of people, businesses and things communicating, transacting through the internet is increasing, which in turn force organizations to adopt digital business strategies.

Digital business is the defined by Garner as “the creation of new business designs by blurring the digital and physical worlds.” It is very obvious that it disrupts existing business models, and the business architecture experts should be prepared to build business architecture references that will help their organizations respond to the opportunities and threats of digital business.

At the beginning the EA team should ensure that their organization has a clearly defined Digital Business Vision and Strategy. This strategy should include: Business long-term goals and policies, analysis of the digital business context and identification of the organization gaps and capabilities of business and technology.

The EA team should ensure that the technology/solutions drives the initiatives. The problem should be set around the business objectives to be achieved, and the BA team along with the rest of the EA team should act as facilitators who helps the business subject matter experts in exploring the wide range of the digital solutions.

Digital business comes with so much integration points. BA and EA team members should ensure that these touch points are safeguarded and well governed. They should also develop roadmaps to achieve higher level maturity of emerging digital business technologies.

In general, the BA team needs to understand and assess the entire digital ecosystem in which their organization may operate and identify which digital business capabilities are relevant to them, and therefore, advice on the appropriate Business models that the organization can adopt to achieve specific business outcomes.

There are information on this interesting topic, which can be found in this link:

https://www.gartner.com/document/code/272022?ref=grbody&refval=3184620

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!