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 20th.
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:
That’s all about application architecture, see you soon!
