EA, as the name states, is the architecture that is the integrated blueprint of the enterprise. It, simply put, describes the enterprise from the many angles that serve its various stakeholders.

Hence, EA, as an architecture, is to be employed to
 * simplify the enterprise
 * operation improvement,
 * cost reduction
 * align of technology operation to the business wants
 * align of the enterprise components evolution to strategy
 * analyse business models
 * create an an enterprise wide transformation project portfolio
 * guide decisions and investment

In more general terms, EA is employed to ease complexity and change management.  The EA may be asked to do strategy but only for IT but this not necessarily an EA task.

The purpose of an EA framework is to enable the delivery of the EA, that is the architecture of the enterprise, rather than solving the problems of the enterprise.

The EA itself, once created, would be employed by stakeholders (clients) to achieve their specific goals such as fixing process issues, enterprise standardisation, integration, technology alignment to business operation, investment decisions, strategy implementation... in which activities, the EA architect may not be called to assist at all.

Once the architect delivers a proper EA framework and EA, he succeeds, more or less, to make own self redundant.

EA is successful if it delivers the integrated EA architecture with views for most of its stakeholders (for example top management, finance, IT development, Quality improvement etc) enabling them to achieve their own work objectives in alignment with the enterprise strategy.

If the EA team engages only in policing efforts around the enterprise, without delivering a reference EA, then the EA team failed. The EA blueprint should be used by stakeholders, as much as possible, without the engagement of the architects. The architects are not the factotum of the enterprise.

But the definition of the EA states more than its purpose. It has to answer the What then other W like questions such as Why, Who, How...

It denotes the EA practice that should collaborate and coordinate the many other activities in an enterprise to discover, design and implement the EA and the enterprise target state.
EA also means the EA team that manages the enterprise.

Windows Azure AD Access Control

Why do we need Azure Access control?
It helps us to easily manage access to your applications based on centralized policy and rules. Ensure consistent and appropriate access to your organizations applications is maintained to meet critical internal security and compliance needs. Windows Azure AD Access Control provides developers centralized authentication and authorization for applications in Windows Azure using either consumer identity providers or your on-premises Windows Server Active Directory.

Consider the following security knobs in Windows Azure AD Access Control deployment. The information below is a digest from ACS Security Guidelines and Certificates and Keys Management Guidelines.

• STS tokens expiration. Use Windows Azure AD Access Control management portal to set aggressive token expiration.
• Data validation when using the Error URL feature. Windows Azure AD Access Control Error URL feature requires anonymous access to the app’s page where it sends error messages. Assume all data coming to this page as dangerous from untrusted source.
• Encrypting tokens for highly sensitive scenarios. To mitigate threat of information disclosure that available in the token consider encrypting the tokens.
• Encrypting cookies using RSA when deploying to Windows Azure. WIF encrypts cookies using DPAPI by default. It creates server affinity and may result in exceptions when deployed to web farm and Windows Azure environments. Use RSA instead in web farm and Windows Azure scenarios.
• Token signing certificates. Renew token signing certificates periodically to avoid denial of service. Windows Azure AD Access Control signs all security tokens it issues. X.509 certificates are used for signing when you build an application that consumes SAML tokens issued by ACS. When signing certificates expire you will receive errors when trying to request a token.
• Token signing keys. Renew token signing keys periodically to avoid denial of service. Windows Azure AD Access Control signs all security tokens it issues. 256-bit symmetric signing keys are used when you build an application that consumes SWT tokens issued by ACS. When signing keys expire you will receive errors when trying to request a token.
• Token encryption certificates. Renew token encryption certificates periodically to avoid denial of service. Token encryption is required if a relying party application is a web service using proof-of-possession tokens over the WS-Trust protocol, in other cases token encryption is optional. When encryption certificates expire you will receive errors when trying to request a token.
• Token decryption certificates. Renew token decryption certificates periodically to avoid denial of service. Windows Azure AD Access Control can accept encrypted tokens from WS-Federation identity providers (for example, AD FS 2.0). An X.509 certificate hosted in Windows Azure AD Access Control is used for decryption. When decryption certificates expire you will receive errors when trying to request a token.
• Service identity credentials. Renew Service Identity credentials periodically to avoid denial of service. Service identities use credentials that are configured globally for your Windows Azure AD Access Control namespace that allow applications or clients to authenticate directly with Windows Azure AD Access Control and receive a token. There are three credential types that Windows Azure AD Access Control service identity can be associated with: Symmetric key, Password, and X.509 certificate. You will start receiving exception when the credentials are expired.
• Windows Azure AD Access Control Management Service account credentials. Renew Management service credentials periodically to avoid denial of service. The Windows Azure AD Access Control Management Service is a key component that allows you to programmatically manage and configure settings for your Windows Azure AD Access Control namespace. There are three credential types that the Management service account can be associated with. These are symmetric key, password, and an X.509 certificate. You will start receiving exception when the credentials are expired.
• WS-Federation identity provider signing and encryption certificates. Query for WS-Federation identity provider’s certificate validity to avoid denial of service. WS-Federation identity provider certificate is available through its metadata. When configuring WS-Federation identity provider, such as AD FS, the WS-Federation signing certificate is configured through WS-Federation metadata available via URL or as a file. After the WS-Federation identity provider configured use Windows Azure AD Access Control management service to query it for its certificates validness. When the certificate expires you will start receiving exceptions.

A simple search on 'google' on what is windows azure will tell you that Windows Azure is a cloud computing platform and infrastructure, created by Microsoft, for building, deploying and managing applications and services through a global network of Microsoft-managed datacenters. It provides both platform as a service (PaaS) and infrastructure as a service (IaaS) services and supports many different programming languages, tools and frameworks, including both Microsoft-specific and third-party software and systems. And it looks like following diagram....


In a quick span shot :

• cloud service role: A cloud service role is comprised of application files and a configuration. A cloud service can have two types of role:

• web role:A web role provides a dedicated Internet Information Services (IIS) web-server used for hosting front-end web applications.
  
• worker role: Applications hosted within worker roles can run asynchronous, long-running or perpetual tasks independent of user interaction or input.
  

• role instance: A role instance is a virtual machine on which the application code and role configuration run. A role can have multiple instances, defined in the service configuration file.
  
• guest operating system: The guest operating system for a cloud service is the operating system installed on the role instances (virtual machines) on which your application code runs.
  
• cloud service components: Three components are required in order to deploy an application as a cloud service in Windows Azure:
  

• service definition file: The cloud service definition file (.csdef) defines the service model, including the number of roles.
  
• service configuration file: The cloud service configuration file (.cscfg) provides configuration settings for the cloud service and individual roles, including the number of role instances.
  
• service package: The service package (.cspkg) contains the application code and the service definition file.
  

• cloud service deployment: A cloud service deployment is an instance of a cloud service deployed to the Windows Azure staging or production environment. You can maintain deployments in both staging and production.
  
• deployment environments: Windows Azure offers two deployment environments for cloud services: a staging environment in which you can test your deployment before you promote it to the production environment. The two environments are distinguished only by the virtual IP addresses (VIPs) by which the cloud service is accessed. In the staging environment, the cloud service's globally unique identifier (GUID) identifies it in URLs (GUID.cloudapp.net). In the production environment, the URL is based on the friendlier DNS prefix assigned to the cloud service (for example, myservice.cloudapp.net).
  
• swap deployments: To promote a deployment in the Windows Azure staging environment to the production environment, you can "swap" the deployments by switching the VIPs by which the two deployments are accessed. After the deployment, the DNS name for the cloud service points to the deployment that had been in the staging environment.
  
• minimal vs. verbose monitoring: Minimal monitoring, which is configured by default for a cloud service, uses performance counters gathered from the host operating systems for role instances (virtual machines). Verbose monitoring gathers additional metrics based on performance data within the role instances to enable closer analysis of issues that occur during application processing. For more information, see How to Monitor Cloud Services.
  
• Windows Azure Diagnostics: Windows Azure Diagnostics is the API that enables you to collect diagnostic data from applications running in Windows Azure. Windows Azure Diagnostics must be enabled for cloud service roles in order for verbose monitoring to be turned on.
  
• link a resource: To show your cloud service's dependencies on other resources, such as a Windows Azure SQL Database instance, you can "link" the resource to the cloud service. In the Preview Management Portal, you can view linked resources on the Linked Resources page, view their status on the dashboard, and scale a linked SQL Database instance along with the service roles on the Scale page. Linking a resource in this sense does not connect the resource to the application; you must configure the connections in the application code.
  
• scale a cloud service: A cloud service is scaled out by increasing the number of role instances (virtual machines) deployed for a role. A cloud service is scaled in by decreasing role instances. In the Preview Management Portal, you can also scale a linked SQL Database instance, by changing the SQL Database edition and the maximum database size, when you scale your service roles.
  
• Windows Azure Service Level Agreement (SLA): The Windows Azure Compute SLA guarantees that, when you deploy two or more role instances for every role, access to your cloud service will be maintained at least 99.95 percent of the time.