Technical Architect Questions & Answer

An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.
Its primarly consists of four points-of-view, called the business perspective, the application perspective, the information perspective, and the technology perspective.
-The business perspective defines the processes and standards by which the business operates on a day-to-day basis.
-The application perspective defines the interactions among the processes and standards used by the organization.
-The information perspective defines and classifies the raw data (such as document files, databases, images, presentations, and spreadsheets) that the organization requires in order to efficiently operate.
-The technology perspective defines the hardware, operating systems, programming, and networking solutions used by the organization.
Purported advantages of having an enterprise architecture include improved decision making, improved adaptability to changing demands or market conditions, elimination of inefficient and redundant processes, optimization of the use of organizational assets, and minimization of employee turnover.

In medium-to-large for-profit organizations, the primary business stakeholders include executive management: Chief Executive Officer (CEO), Chief Financial Officer (CFO), Chief Operations Officer (COO), Chief Technology Officer (CTO), and Chief Information Officer (CIO). There are others emerging in industry such as the Chief Security Officer (CSO). These “C-level” managers are generally the leadership of a company or organization. These roles may have different titles, or one person may assume multiple roles, but the responsibilities associated with these roles do not greatly vary.
Often, secondary business stakeholders will emerge for a particular solution. A sales and marketing–driven solution might include the director of marketing and a manufacturing solution might include key production management.
Generally, there is a strong financial component around the business strategy. In addition, regulatory mandates drive many business decisions.

An architectural style, sometimes called an architectural pattern, is a set of principles—a coarse grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. You can think of architecture styles and patterns as sets of principles that shape an application.
Patterns are a means of representing, sharing and reusing knowledge. Patterns should include information about when they are and when they are not useful. Patterns may be represented using tabular and graphical descriptions

To understand this, we must take a step back to understand what influences the direction that our companies take. There are direct and indirect influences—or forces—that determine the course of a company. These forces can change as time progresses, so that predicting them can be very difficult. Business SMEs often understand these forces very well, as they keep their eyes and ears on them to qualify their decisions. Architects must do the same.
IT has become less of a function of strategic value to companies—no longer a necessary evil or cost center, but a real differentiating factor in the business of a company. Architects who have an understanding of forces will provide inherent alignment with the goals and objectives of a company.
Forces can be grouped into three high-level groups. These groups include the following:
•External—Forces that are outside the organization forces and cannot be controlled
•Business—Purely business-related forces that can be derived from the inside or outside
•Internal—Forces that originate from the specific culture and operating model of a company

An enterprise architecture into four categories, as follows:
1.Business architecture—Describes the processes the business uses to meet its goals
2.Application architecture—Describes how specific applications are designed and how they interact with each other
3.Data architecture—Describes how the enterprise datastores are organized and accessed
4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions

Foundation Architectures. These are architectural principles that can, theoretically, be used by any IT organization in the universe.
Common Systems Architectures. These are principles that one would expect to see in many—but, perhaps, not all—types of enterprises.
Industry Architectures. These are principles that are specific across many enterprises that are part of the same domain—such as, in our MedAMore case study, all pharmaceutical enterprises.
Organizational Architectures. These are the architectures that are specific to a given enterprise, such as MedAMore.

The EA needs to be well-respected and influential. To be able to conceptualize and promote data management initiatives
The EA needs to be well versed in and able to emphasize methodology, modeling, and governance
Great EAs need to be technologically and politically “neutral.”
High-performing EAs also should be articulate, persuasive, and good salespeople.
EAs need to have enthusiastic qualities.

Technical staff frequently talk about the need for service-oriented architecture (SOA), but rarely in terms that business managers understand. We can sum up the benefits of SOA in three words: control, agility and cost.
If your technical staff can’t tell you how SOA has an impact on those three business needs, you need to tell them to keep trying until they do – otherwise, they’re in serious danger of implementing technology for technology’s sake.

Calculating ROI on projects involving new technologies or emerging IT approaches like Service-Oriented Architecture (SOA) is frequently more of an art than a science.
What makes calculating the ROI of SOA even more challenging is that architecture, by itself, doesn’t offer specific features that companies can readily identify with some particular return. After all, architecture is an investment that companies must make well in advance of any return, and must continue to make over the lifetime of their SOA implementations. How, then, can managers calculate the ROI of their SOA initiatives before those projects take place? What are the tangible benefits of SOA that can result in a quantifiable ROI for the implementers? On the other hand, how should companies calculate the expected return that those tangible benefits will provide to the organization? Only by understanding the full range of SOA value propositions can companies begin to get a handle on calculating the ROI of SOA, and even then, it may be impossible to understand SOA’s true ROI before the project is complete, because SOA addresses issues of fundamentally unpredictable business change.

Value Chain Analysis describes the activities that take place in a business and relates them to an analysis of the competitive strength of the business. The business activities could be grouped under two headings:
(1) Primary Activities - those that are directly concerned with creating and delivering a product (e.g. component assembly); and
(2) Support Activities, which whilst they are not directly involved in production, may increase effectiveness or efficiency (e.g. human resource management). It is rare for a business to undertake all primary and support activities.
Value Chain Analysis is one way of identifying which activities are best undertaken by a business and which are best provided by others ("out sourced").

The Architecture roadmap is the master map for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).

• Scope
• Goals, objectives, and constraints
• Architecture principles
• Baseline Architecture
• Architecture models (for each state to be modeled):
• Business Architecture models
• Data Architecture models
• Application Architecture models
• Technology Architecture models