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 !

Translating the strategy

Gartner defines Enterprise architecture as “the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise's future state and enable its evolution.”  We have been taught that our architecture efforts should be fully aligned with the corporate strategy and that business should be fully engaged. The question is how can we achieve this?

It all starts with understanding where your organization is heading to?  What are its explicit and implicit goals? Even if it is not well articulated, you should be able to discover and derive the strategy, in order to define the business context on which your EA work will be based.  Sources like annual reports, presentations to stockholders and senior management communications can be of great help.

You should also invest some time in trying to understand the environmental forces that affect the enterprise and the enterprise strategic responses to them. These forces can be internal such as budgetary constraints and organizational culture or external such as technology trends, competition and changes in regulations.

Stakeholders is another great source; both internal and external. You can get significant insights and inputs from stakeholders across all the levels of the enterprise from the senior executive team to the line management, the support functions and IT operations. Contractors and service providers’ perspectives should also be considered as it may shed the light on some of the strategic drivers of the enterprise.

Once you have something solid in hand to be presented, go and validate it. Engage with the stakeholders in workshops and use what you have to guide the conversations. You will probably encounter different views and colliding perspectives. Nevertheless, everything will eventually synergize as you continue to refine your work. Towards the end, everybody will agree on a set of business outcomes that must be achieved.

Now that  you have a big picture of the enterprise, its critical business issues and priorities. You can start stage planning your business outcome-focused architecture into iterations. This way, your EA program’s value to the business can be perceived, measured and appreciated.

Have a nice week!

An Enterprise Architecture Balanced Scorecard

We are approaching the digital business era where enterprise architecture (EA) has tremendous value to offer. The practice of EA has evolved over the past few years, yet, most EA programs do not have structured approach to measurement and reporting. They fail to communicate their performance and value to the enterprise.

 Some of these organizations EA is seen as a staff function that is hard to be measured. Other organizations are not very clear what to measure the EA program alignment with projects or the EA process quality and value.

According to Forrester, “A small set of contextually relevant metrics puts the EA program in the context of organization goals and outcomes”. Forrester has developed an Enterprise Architecture Balanced Scorecard (EABSC) with the following four perspectives:

• Health. Intended to measure the current fitness level of a tech management organization and the technology landscape it supports with the support of the EA practice.

• Service.  Intended to measure how EA can help the tech management in delivering services through the use of reference architectures and patterns and projects architecture review.

• Outcome. Intended to measure direct contributions to business outcomes.

• Agility. Intends to measure the EA agility and responsiveness to rapidly changing business needs architectures for technology, service, and application portfolios.

I liked the Forrester approach so much. I do agree with Forrester that there is no excuse for not measuring your program. I will certainly use this balance scorecard to select metrics to measure my EA program in the future.

Enterprise Architecture matters

Now, I can see why Enterprise architecture matters. I am super busy this week therefore I am sharing this short insights.

Back in 2006, ABC’s new CIO had a very difficult time accepting the IT road map developed two years before. One of the problematic areas was definitely that the proposed solution architectures and models were vendor specific. This was due to the fact that the consultancy firm that developed the road-map and the implementer was the same entity!  How Ironic!

We were asked to start clear and carry out enterprise wide requirement analysis exercises. Our work resulted an enterprise business model that is technology independent. We were able to carry out current state assessment and see where we fall in the maturity ladder. I do recall that this current state assessment had enable us to gain the trust of the sponsor and executive team. For the first time in our department, we were able to understand the problem before soliciting the vendors to propose solutions. 

Further to the last example of our work in ABC in 2006, the enterprise wide models developed by our team, have enabled us to identify common concepts that can be reused in different functional components. These concepts were later developed into enterprise-wide modules. This was effective in so many levels I do not need to count.

Isn't this simply great.