While reading several articles and seeing videos about cloud computing, I wrote notes when I found something interesting. IMO, these notes can give a good summary of many distinct views about this and other related subjects, so I'm posting them here:

According to a 2008 paper published by IEEE Internet Computing “Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, tablet computers, notebooks, wall computers, handhelds, sensors, monitors, etc.”

Cloud computing is often confused with grid computing, (a form of distributed computing whereby a "super and virtual computer" is composed of a cluster of networked, loosely-coupled computers, acting in concert to perform very large tasks), utility computing (the packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility such as electricity) and autonomic computing (computer systems capable of self-management). Indeed many cloud computing deployments are today powered by grids, have autonomic characteristics and are billed like utilities, but cloud computing can be seen as a natural next step from the grid-utility model. Some successful cloud architectures have little or no centralized infrastructure or billing systems whatsoever including peer-to-peer networks like BitTorrent and Skype and volunteer computing like SETI@home.

The majority of cloud computing infrastructure currently consists of reliable services delivered through data centers that are built on servers with different levels of virtualization technologies. The services are accessible anywhere in the world, with The Cloud appearing as a single point of access for all the computing needs of consumers. Commercial offerings need to meet the quality of service requirements of customers and typically offer service level agreements. Open standards and open source software are also critical to the growth of cloud computing.

It is a very confusing topic: services are called cloud, platform is being called cloud, and also virtualized infrastructure as a service is being called cloud. The cloud is the Internet.

Just as we moved from mainframe to client-server applications, we are now moving to the cloud.

If there is something new, that would be a refactoring of the way we think about operating systems, the way we think about client systems and the way we think about running software.

Cloud computing is actually the emerging IT development, deployment and delivery model that enables real-time delivery of products, services and solutions over the Internet.

It is the evolution of Internet-based computing.

It is the availability of huge numbers of business and consumer services.

It is the ability of deliver those services with the best quality possible.

It is the promise of making the experience for the users far better than today.

It is an evolution of On-Demand Computing. People don't want to know about the software. They care about the business services, not the implementation underneath. In this sense, everything is virtualized as possible, including the services themselves.

Computing still asks for too much care, but all that has to disappear. It should just do its job and shut up.

The delivery mechanism for cloud services is the data center, in the same way that the delivery mechanism for manufacturing plant is for consumer electronic devices. So if you want to compete in high-level areas, you have to offer really good quality (my note: this also is called Utility Computing, like offered by Amazon).

Very few people want SaaS. The majority of people want service as a service. It is not about the software people care about, but the service offered. That is why services must work transparently in relation to their software.

The cloud is all about the evolution and industrialization of the data center. It is how you build it to be able to deliver billions of services with 100% availability, privacy, identity, security and systems management and the very minimal amount of energy possible. It is all about delivering quality infrastructure for services.

While Amazon Web Services, Google, and other players claim to offer cloud services today, the reality is far from the vision. These companies offer little more than online storage and/or email -- with indifferent support and unpredictable performance. Larger-scale cloud services from IBM and other big vendors are usually priced out of range for all but the largest shops.

There is more to know about besides Utility Computing: what new business models it offers? How to make money in the cloud?

Is about abstracting the way applications use their underlying infrastructure.

“Information Bank” analogy: security, new information for value-added information.

On-premises or the Cloud: which one is better? It depends if you are optimizing for cost or for control. By adopting a hybrid strategy, it is possible to tap into economy of scale where possible while maintaining flexibility and agility where necessary.

The Cloud is the next evolution of where the web computing is going and a way of abstracting the services and applications away from the physical resources.

Cloud Layers:

1. Application Layer (SaaS)

2. Platform/Middleware Layer (Platform as a Service)

3. Infrastructure Layer (Infrastructure as a Service) (ex: Amazon) – The Long Tail is here

4. IT Foundation

We need standards to make the Cloud happen. So the private clouds can talk to each other and be part of the bigger cloud (hybrid clouds). We also need Federation to happen. That would be an Intra Cloud. We’ll get there faster than previous architecture generations did.

Infrastructure as a Service (IaaS) is a big opportunity.

It is not so much about cost, but about flexibility and speed of delivery. The advantage of cost depends of the business and what they are trying to do.

This is more about the information revolution and not about the computing revolution.

The current model of the cloud is not sustainable. The nature of work is changing. The way we work will change through mobility. It is all about collaboration.

Services that understand who you are and where you are and can provide you information in that context are going to be very exciting.

The cloud will be simply on the web and the for the new generations this will be like air, they will not see it at all.

Everything will connect to the BIG computer we are building.

Cloud computing allows for micro-innovation, meaning that a single individual now can create and deliver a program without big upfront investments.

There will be more vertical software that will demand for better SLAs.

There will be issues: content and ownership.

People will depend more and more of the cloud services. They will be like electricity. You’ll miss it when it fails, but you never think about the power grid behind it when you use it.

Cloud suppliers will want people to depend of their particular electricity supply. This will create lock-in. It is hard to change providers, for example, if a service is on Microsoft infrastructure, it will be difficult to change it to Amazon.

Federation will succeed because it will be a way of small groups to join and compete with bigger and wealthy companies.

There is a new dialog that has to be done about the consequences of the technology innovators create and this will bring a need for regulation. This is also about changing the culture of people who creates technology so they have more commitment.

Cloud computing will allow for applications that we cannot even imagine now.

Being part of the economy, cloud computing will have social consequences. It will have dramatic benefits for everyone’s productivity.

We will throw away many things in the long term, for example the desktop OS we use now can be one of them.

My data will be synchronized no matter where I am and what platform or device I’ll be using.

In a way, cloud computing is like a first step in the direction of a having a hive mind.

Cloud computing is going to transform the way we do computing, not in 10 years, but in 4 or 5.

It is also a global step towards efficiency. It is expected that even governments will adopt the cloud computing technologies faster than we expect now because of social demand for global services. That will lead to Government 2.0.

It is easy to build a useful service right now without thinking about the long term and social consequences.

Understanding the services you use is critical. How do they deal with personal information? For example, there are currently no standards about information storage and durability. Collecting personal information can be hazardous in the long term. Should the cloud providers be obliged to keep it forever? Just like it is easy to use cloud services now to publish information about anything, it is also possible to use that power to either follow a person’s behavior. Maybe we should have regulation about what to do with information in the long term.

It is also critical to know what data is trustable (coming from a reliable source) and what is not.

Newer generations have a more sophisticated attitude regarding personal information because we are increasingly living in a transparent society.

Just like with civil engineering, building applications for the cloud will have regulations that will make people more confident their rights are respected so they will not think about it, just like they don’t think about if there is a fire when they enter a conference room. The standards compliance will be assumed.

The digital divide will be every time greater, between the people with access to the services that can make a difference in every aspect of living, and the people who don’t.

Uses of select cloud services:

- 56% of internet users use webmail services such as Hotmail, Gmail, or Yahoo! Mail.

- 34% store personal photos online.

- 29% use online applications such as Google Documents or Adobe Photoshop Express.

- 7% store personal videos online.

- 5% pay to store computer files online.

- 5% back up hard drive to an online site.

The value of using cloud services:

- 51% of internet users who have done a cloud computing activity say a major reason they do this is that is easy and convenient.

- 41% of cloud users say a major reason they use these applications is that they like being able to access their data from whatever computer they are using.

- 39% cite the ease of sharing information as a major reason they use applications in cyberspace or store data there.

- 34% say they value the fact that they won’t lose data if their computer fails.

What worries users:

- 90% of cloud application users say they would be very concerned if the company at which their data were stored sold it to another party.

- 80% say they would be very concerned if companies used their photos or other data in marketing campaigns.

- 68% of users of at least one of the six cloud applications say they would be very concerned if companies who provided these services analyzed their information and then displayed ads to them based on their actions.

- 63% say they would be very concerned if a company were to keep a copy of files even if they try to delete them.

- 49% say they would be very concerned if a company gave law enforcement agencies your files when asked to do so.

The internet anchors in people lives as a social and participatory tool. People value the cloud as a means of exchanging information with others. People generally start to worry when their data is used in ways that they did not anticipate.

Client-Server Platforms:

- Time to Value in Months

- Fragmented Security & Compliance

- Painful, Risky Upgrades and Updates

- Expensive multi-year software licenses

- Difficult to Customize and Use

- Complex Infrastructure

Cloud Computing:

- Time to Value in Weeks

- Central Security & Compliance

- Automatic Upgrades

- Monthly Subscription Payments

- Easy to Customize and Use

- No Infrastructure

We’ve got huge challenges with cloud computing. This will be as important as the web was, 15 years ago. We need competition to happen in this market, because that will lead to the innovation we need and that innovation will lead us to all sort of new applications.

Users want their data treated on the cloud the same way as it was on their computer. Users don’t understand if they are using the cloud things can be different. These will require proper education and policies.

There will also be lots of private clouds. Governmental organizations will want to have their private clouds and some private companies also.

Cloud service providers must be transparent regarding their quality of service and the way they collect data.

The cloud will be an incredible enabler that can help in international development, because they don’t need to worry about the services and infrastructure. If we do the cloud right, also some of current security problems will disappear and so the Internet will be more secure.

It will become a competitive necessity to use the cloud infrastructure so the businesses can benefit from greater quality at reduced costs.

An hundred years ago, we arrived at such a moment with the technologies that extend man’s physical powers. We are at another such moment today with the technologies that extend our intellectual powers.

As information utilities grow in size and sophistication, the changes to business and society –and to ourselves- will only broaden. And their pace will only accelerate.

It is not easy to keep pace with Microsoft projects and products naming. There are literally dozens of names to follow and sometimes it seems they change so fast we are already skipping some when we check them! In order to help others (and myself) with this task, I'm writing this post.

This obviously will not be a revelation for many of us, but I think it is helpful to aggregate all the names in one place so anyone can look for a specific name and get a small description of it, without having to search the web trying to understand how the whole thing fits together.

I really want to give due credit to the sources I used, so please check the links I'm referring to at end of this post and read them whenever you need to know the full details of each topic.

Azure: Is a group of cloud technologies, each providing a specific set of services to application developers.

Azure Services Platform: Can be used both by applications running in the cloud and by applications running on local systems. Its components include: Windows Azure, .NET Services, SQL Services and Live Services. This is what was briefly known as "Windows Strata".

Windows Azure: Is a cloud services operating system that serves as the development, service hosting and service management environment for the Azure Services Platform. It provides a Windows-based computing and storage environment in the cloud and is what networks and manages the set of Windows Server 2008 machines that comprise the Microsoft-hosted cloud. At the highest level, has four components: Storage (like a file system); the "fabric controller", which is a management system for modeling/deploying and provisioning; virtualized computation/VM; and a development environment, which allows developers to emulate Windows Azure on their desktops and plug in Visual Studio, Eclipse or other tools to write cloud applications against it. This is what used to be code-named "Red Dog".

.NET Services: Are a set of Microsoft-hosted, highly scalable, developer-oriented services that provide key building blocks required by many cloud-based and cloud-aware applications. Much like the .NET Framework provides higher-level class libraries that make developers more productive, .NET Services allows a developer to focus on their application logic as opposed to building and deploying their own cloud-based infrastructure services. The current services set include: .NET Access Control Service, .NET Service Bus and .NET Workflow Service. These services were previously known as "Zurich" and later as "Biztalk Services".

.NET Access Control Service: Provides an enterprise-class mechanism for enforcing access control rules and authorization as a web service. It supports federated scenarios to support enforcement of access control rules where users may come from multiple organizations or utilize different identification protocols.

.NET Service Bus: Enables secure connectivity between services and applications behind firewall or network boundaries, facilitating cross-organizational communication. Additionally the service bus allows service functionality to be exposed easily and consumed from other applications in a loosely coupled manner using a variety of communication patterns. Creating an infrastructure to facilitate this type of communication involves significant challenges related to authentication, naming, and secure cross organizational firewall traversal. The .NET Service Bus provides a hosted, secure, standards-based infrastructure that dramatically reduces the barriers to applications communicating across systems and organizational boundaries.

.NET Workflow Service: Is a hosted offering that executes user defined declarative workflows in a scalable and reliable manner, greatly simplifying the need to write complex code to orchestrate the interactions between services. The Workflow service allows you to declaratively configure a predefined set of activities and works as an agent to manage and execute the interactions between services.

SQL Services: Provides a cloud database today through SQL Data Services, with more cloud-based data services planned. Delivers on Microsoft’s Data Platform vision of extending the SQL Server capabilities in cloud as web-based services. It enables you to store data from structured, semi-structured, and unstructured documents. SQL Services will deliver a rich set of integrated services for relational database, search, reporting, analytics and data synchronization with mobile users, remote offices and business partners.

SQL Data Services: Offers highly scalable and Internet-facing distributed database services for storing and processing relational queries. It helps you develop and provision new applications quickly with REST and SOAP based web protocols. The services are built on robust SQL Server database and Windows Server technologies, providing high availability and security.

Live Framework: The Live Framework is a simple, open, and interoperable framework for developers to access Live Services from a variety of platforms, programming languages, applications and devices.

Live Services: Through the Live Framework, provides access to data from Microsoft’s Live applications and others. The Live Framework also allows synchronizing this data across desktops and devices, finding and downloading applications, and more.

Dublin: Extensions to the Windows Server application server, that provide improved server support for running and managing service-oriented business logic. Dublin extends the Windows Process Activation Service (WAS) and Internet Information Services (IIS) 7 with support for Windows Communication Foundation (WCF) and WF-based applications. Dublin will initially be made available for download and use by Windows Server customers, then later included directly in future releases of Windows Server.

Oslo: A group of technologies aimed at creating and running model-driven applications and more. The Oslo technologies include a repository, providing a common place to store a range of information about your IT environment; a modeling language family, code-named M, for describing that information; and a modeling tool, code-named Visual Studio Quadrant, for working with repository information.

M - The Oslo Modeling Language: Is a modern, declarative language for working with data. M lets users write down how they want to structure and query their data using a convenient textual syntax that is convenient to both author and read. This language was briefly known as "D" Language.

Quadrant - The Oslo Design Surface: Is a tool for interacting with data and it is completely data-driven. In the current supported implementation, it stores every bit of data in SQL Server. You have a canvas where you can drag everything you can work with on that canvas. Icons that are blue can be dragged out and placed on the canvas again to get a full view of that item again. That way you can drill down on all models.

The Oslo Repository: Is a SQL Server 2008 database for storing all types of metadata and models for the enterprise. The repository plays a central role in the "Oslo" vision of creating a platform for building and managing applications. "Oslo" modeling platform tools and technologies rely on models to design, develop, deploy, and manage these applications. The Repository provides a central location to store and retrieve these models, which makes it a unifying foundation for all of "Oslo" modeling platform.

Geneva Server: Is the next release of Microsoft’s Active Directory Federation Services (AD FS). It also provides broad support for claims-based identity. For example, unlike its predecessor, the Geneva Server implements an STS that generates SAML tokens in response to WS-Trust requests. Also unlike AD FS, which supported only Web browsers, the Geneva Server supports both browsers and other clients, such as those built using Windows Communication Foundation (WCF). This means the Geneva Server supports both active and passive clients, while AD FS supported only passive clients. Another important difference from the original AD FS is that the Geneva Server supports both WS-Federation and the SAML 2.0 protocol, letting it work in a broader range of environments.

CardSpace Geneva: Is the successor to an existing Microsoft technology, the original CardSpace. This identity selector can be used both with Web browsers, including Internet Explorer and Firefox, and with other Windows clients, such as WCF applications.

Geneva Framework: Is a set of .NET Framework classes that implement basic functions, such as receiving a token, verifying its signature, accessing the claims it contains, and more. For situations where the Geneva Server STS isn’t sufficient, the Geneva Framework also provides support for building your own STS. One important example of this already exists: The Geneva Server itself is built on the Geneva Framework. This was previously called "Zermatt".

ADO.NET Data Services: Is a combination of patterns and libraries that enable the creation and consumption of data services for the web. The goal of the ADO.Net Data Services framework is to facilitate the creation of flexible data services that are naturally integrated with the web, using URIs to point to pieces of data and simple, well-known formats to represent that data, such as JSON and plain XML. This results in the data service being surfaced to the web as a REST-style resource collection that is addressable with URIs and that agents can interact with using the usual HTTP verbs such as GET, POST or DELETE. Many of the Microsoft cloud data services (Windows Azure tables, SQL Data Services, etc.) expose data using the same REST interaction conventions followed by ADO.NET Data Services. This enables using the ADO.NET Data Services client libraries and developer tools when working not only with on premises services created using the ADO.NET Data Services Framework, but also with hosted cloud services. This was formerly known as Project "Astoria".

Visual Studio Team System 2010: Is the next version of Visual Studio and .NET Framework. This was code-named "Rosario".

(...)

I'll try to keep this post updated. Meanwhile, in case you want to read the whole stories, here are my sources:

Azure Services Platform FAQ

Microsoft’s Azure cloud platform: A guide for the perplexed

Introducing Geneva

An Overview of the Azure Services Platform

Workflows, Services, and Models - A First Look at WF 4.0, “Dublin”, and “Oslo”

The Oslo Modeling Language, Draft Specification - October 2008

"Oslo" Repository Overview

"Oslo": Customizing and Extending the Visual Design Experience

ADO.NET Data Services

A Short Introduction to Cloud Platforms

In my first post about the subject, I've focused on what service orientation is not. In this second post, I'm writing about what I think service orientation really is:

1) Exposes business processes as services:

SO impacts vertically your organization, and may/should change the way you think about and develop software. You will be more and more focused on exposing every process in your organization as a service and not just developing single components. In your analysis/modeling phases, you'll think more about what candidates you have for being a service, your development process assembly line will give more attention to composition and integration of services and less to construction of components, and you'll have the need to ensure that every service you do is validated against best practices and registered somewhere so you can find it, whenever you need it. This means you'll need a well structured development process in order to be able to produce many small building blocks of directly reusable business assets.

2) Is standards-based:

While it is possible to implement services without thinking about standards, this does not means you should do it. SO is about standardization. Yes, this means you must not demand your outside consumers to understand and support your internal version of a markup language. You should keep it as an internal implementation detail and expose an adapter or facade with a standard interface to outside consumers. Also remember you don't know every possible use case a service can participate in the moment you deploy it. If you want to support unknown consumers, you'll be better implementing standards-based services. By the way, using a Schema-First or Contract-First approach can help a lot on this, as the basis for enforcing standardization best practices.

3) Provides cross-platform interoperability:

As a consequence of 2), interoperability will be achieved through SO practices. For example, as a C# programmer, the next time you'll need something from that Perl, Python, PHP or Java team, you'll know you can have it. Just ask for a service. Everyone will know what you are talking about: a reusable component with a standards-based interface and an address you can use to consume it. You can have your services consumed by any Windows, Linux or Macintosh client, and this means real cross-platform interoperability, not just interoperability between different versions of Windows.

4) Delivers a catalog of reusable services:

If you have more than half a dozen services, you'll need a services catalog. Note that if every service has about 8 operations in it, you'll have at least 48 operations to care about in those half a dozen services. Experience showed me that the number of services in a organization will grow fast in the adoption phase of SO because you'll want every aspect of your business reusable as a service can be. By the way, this catalog will be what you make of it. If you produce a services list and just maintain it to be able to find a service name or operation by its description or tagging, than you'll have a services directory. Or you can ask for more, and have registered in your catalog their dependencies of other services and applications in production, so you can develop a notifications system that will tell you what is affected, when a service is down. I don't think you'll achieve SO governance without having a catalog.

5) Basis of services central administration:

Using a service-oriented development process as mentioned and the catalog described in 4), you can mount a system that allows for central monitoring of resources involved. As I wrote in my previous post, SO is about transparency. You will tell everyone what is happening in every moment. How many Request-Per-Second every operation has, who's consuming it and what is the system health at any time. You'll need policies in place for that. Every time a service is deployed, you'll need to respect some registration procedures so you'll be better making these procedures part of your development process deployment phase. Don't poll your services for problems or you be a SO slave. Try instead to use your services catalog as the information basis you need to implement a push system that notifies responsible people.

6) Improves business agility:

Agility of business is SO promised land. That's why it is worth to do it. After being on the road to SO and starting to have a significant number of services, you'll start benefiting from them. For example, the next mobile project you'll have using some of those business process features you exposed, will be faster to implement, will be less expensive and will have greater quality than if you did it without using SO. Sapo Mobile project is a good example of this. After running SO for about a year, Sapo had enough registered services to be able to design, develop and deploy this project, in only about three months work of three focused people. This means that after reaching some maturity, SO adoption will deliver the agility you expect from it, not necessarily because you can make services faster than classic components, but because you are allowing business logic reuse in totally different contexts.

7) Gives strategic advantage to adopters:

Having the possibility to deliver new lines of business by composing services is very attractive to all business stakeholders. You will have what other competitors don't and that is why it is strategic to have it. The possibility of delivering a new business idea's value in a short time is crucial to be on the top. That said, keep in mind that beyond the LEGO pieces developers do, there is a greater value of SO. People will be using best practices to achieve common goals and, again, that is why SO is all about collaboration, not technology. After realizing SO value, if you try to change it for some other process, people will want to know why. This means the real value of SO is on the people who is doing it.

8) Has a great ROI:

All the previous will lead your business investments to a greater return. While it is obvious that SO adoption will have great costs, all efforts spent will come back through generation of business opportunity the organization could not reach before. You can realize this just after some months, if you carefully chose one not so critical but valuable business process for SO adoption. SO will pay for itself as it goes by, but you have to think of it as a on-going-best-practices-followed-by-people-process, or you make it die. This means you have to follow up on its health, empowering the people who are in place of making it succeed and always keeping an eye on what next challenge will be made.

These last 2 years as software architect and lead developer for Sapo Services project, I learned a lot about what is service orientation and what works better. These conclusions are of course taken from my real-world experience implementing this and other projects I take as an independent consultant and not a law you will see applied in every case. I will make a two-post series on this subject, also giving fundament for every argument I'll present.

I'll begin with what service-orientation is not:

1) It is not easier:

Service orientation is not easier to implement than a monolithic architecture, OOP or CBD. One big ball of anything is obviously easier to do, compared to many separated balls who communicate as a complex system. There are many industry best practices involved in a service orientation project and your knowledge of them is critical to success. You will need good communication skills with all stakeholders and to be specially disciplined as you drive them out of chaos.

2) It is not faster:

Service orientation projects do not take less time to deliver than a classic .NET or Java project. Because applications are more complex, there is little to gain from it in time to market terms. It is faster to continue doing things the same way than changing old habits. You will need people to assume there's need for a change and likewise naturally accept that nothing like what is promised in SO will come for free.

3) It is not cheaper:

You will have new roles with SO advent and this can mean hiring. There is a lot of new technology to deal with and this means training. The organization implementing SO will change dramatically and naturally this implies more cost than before. 

4) It is not revolutionary:

There is nothing new in SO, besides the fact of joining, standardizing and demanding together some of the best practices from previous technologies. This means you are not supposed to forget what you've learned about the best way to build a class or a component. There are specific aspects to consider when doing a service but underlying it we'll need well built components, as before.

5) It is not a product:

No matter what corporate sellers will tell you, ignore them. You can't buy SO. There is a lot more about SO that what will come in that package they will try to sell you. You don't buy business agility, you have to get more agile processes. This requires people to have a common vision and cooperate to fulfill it. SO is all about cooperation and transparency. Will this come in a software box?

6) It is not about just doing services:

Many times I hear people saying they are now service oriented because they have built some services. SO is more about best practices than is about services. Sure, you will have services in SO but you also can have hundreds of services and never reach a service oriented state for your business processes. In fact, SO is much more a road you should follow than a place you can go. I prefer to say: "we are on a way to SO". This makes much more sense to me.

8) It is not self-managed:

Introducing SO, you have lots of new reasons to monitor the systems pro-actively. You need to know a lot about your services: when they fail and why, what is affected and get notified in multiple ways. Even if you are building a super-cool architecture with a lot of P2P agents and smart stuff, service governance will not be done automatically: you will need specific services, applications and the people who operate them.

9) It is not a developers problem:

You may be a bit worried if you hear someone saying that SO is a developer's problem, not our department. But you can get really worried if you hear your CEO saying so. That will mean something is wrong with your SO initiative. Check point 5).

10) Finally, will not vanish if we just sit and wait:

Depending on how much you are allowing your company to loose, you can ignore SO. There have been several trends like this and you are still open to public, I know, but how long will you sustain not having the business agility demanded by customers and showed by competitors? Will you keep your big ball of anything?

After exploring SO misconceptions, in Part II, I will focus on some facts. Until there, please accept my invitation to comment on your own SO experience.

Thanks to Microsoft, Fullsix and Logical Software, who organized and sponsored the first Scrum Master Certification training ever delivered in Portugal, I am now a Certified Scrum Master. As recognized by Mitch Lacey, our Certified Scrum Trainer, the attendees were a very dynamic and focused group that made the training experience very pleasant.

For those of you who didn't had the chance of being there, I decided to compile and share some of my personal notes I wrote during the training. I usually only take note of things that really got my attention or that I want to check in more detail later. I'm doing this sort of a disclaimer because I know none of them will be a revelation to people who already know about Scrum:

- Scrum is one of various agile methodologies available worth checking: DSDM and Crystal Clear are also good examples of those.

- Focus on the on build state, not on the to build state, meaning that we should give more attention to what we are building in every sprint and less in what the final product will be.

- Accept the change always, communicate the impact always. The impact of change should be both communicated to the Team and the Product Owner. It is also Ok to change the Vision. Just always communicate it.

- Check the Team behavior frequently: forming-storming-norming-performing.

- Quality is the only asset which is not negotiable. In the picture below, the left triangle represents the classic Waterfall project management methodology and the right triangle stands for an Agile process. Using Waterfall, we achieve Cost and Schedule estimations through the Plan. With Agile, the project can adapt to business need and that means the Vision is driving Feature estimates.

- Have no more than 3 blocking issues at any time. For example, if a developer has more than three pending tasks waiting for someone or something to happen, then it will be very unlikely that he will be able to know where it was on each of those when it comes back from say, a seventh pending task. It is preferable to ensure one of those three tasks is unblocked before continuing to the next task.

- Yes, scattered teams are a problem. There is no magic solution. Accept facts like time zones. Use video-conference to do daily scrums. Be part of the solution, not the problem.

- Use spikes to do estimation. If the estimate given by the spike compromises the Sprint, then the features should go into the Backlog. Besides that, a spike is just a regular Sprint task.

- Team membership can only change between roles. We should not allow a Team member to change his team in the middle of a Sprint.

- There are 4 main Team Decision Making types: Autocratic, Consultative, Majority and Consensus.

- Skills, Availability and Competency are 3 important criteria when choosing a Team.

- It is worst to have Scrum Master and the Product Owner in the same person. It is Ok to have the Product Owner and the Customer in the same person.

- It is better to have the Team sign up than the Team assigned. That's why they commit to do the work and respect deadlines.

- The true measure of a project progress is: working software.

- Always define with the Team what done means. Will done include tested and deployed?

According to this report, "AMD’s March 2003 introduction of its Opteron processor, followed by Intel’s March 2004 release of a family of x86 64-bit processors under the Xeon brand name, changed the landscape considerably [My note: the landscape of having to use an Itanium processor and either run slower emulated code or revise and recompile to 64-bit]. These processors almost completely closed the divide between 32-bit and 64-bit architectures because systems based on the x86-64 processors can support 32-bit Windows operating systems and 64-bit Windows operating systems. Even better, both 32-bit and 64-bit Windows on x86-64 processors are fully capable of hosting the majority of existing 32-bit Windows applications without performance degradation or recompile".

This support is possible on Windows through WoW64, meaning that you may have the need to support Windows 32-bit on Windows 64-bit, or in other words, to distribute 32-bit applications for 64-bit Windows platforms. In that case, this document describing WoW64 Best Practices may be useful.

That said, although generally speaking we have potential benefits from larger memory support, faster computation and data transfers, we will not always gain performance from this migration. I suggest that if you have doubts on this, evaluate it on a per-case basis: test it before and test it again afterwards. 

So, if you are (like I am) considering to migrate your server installations to 64-bit architecture, you may come across some issues. An example: it is not possible to install TFS 2005 or 2008 on a 64 bit single-server installation: "Team Foundation Server requires that the application tier run in a native 32-bit environment". It is documented in the Installation Guide, for 2005 and here, for 2008. This of course means that in order to use a 64-bit database installation to support TFS, we will need at least another server.

Meanwhile, if you are not sure about what you should do for your development process in order to be ready when and if the migration happens, there's a simple configuration you can use when compiling your C# code: "AnyCPU". This setting will make your application run as a 32-bit application on a 32-bit platform and a 64-bit application on a 64-bit platform, without recompilation (check WoW64 Best Practices and this chat transcript with the 64-bit CLR Team for more details on this).

Being a good architect is not an easy task to do. This January, I was in Norway for the Architect's Master Class with Juval Lowy, from IDesign, and one aspect that I've found interesting in what concerns this course organization is the way Juval assigned time to the 3 main areas we discussed: Process (1 day), Technical (2 days) and Design (2 days). Why I've found it interesting? Well, because it looked a real perspective to me, thinking in the way I'm used to spend my working time nowadays: a portion of project management, a bigger portion with technical lead and also some more time discussing/doing design and prototypes.

In my view and strictly speaking, project management should not be in the architect's roles but in practice, the hybrid-transitional state of our profession requires so. Many times, we don't have the possibility to rely on good-enough (or even existent at all!) project management, so we'll have to do it ourselves in order to ensure the project will accomplish its goals.

Another question that is around for some time now is about if an architect should/must be a good coder. While I can think of a good enterprise architect who knows very well how to lead strategically an organization but he can't be a programmer, if we are thinking of a solutions architect, this competence is not optional. A professional solutions architect generally does not do daily development for a living, but it will be impossible to sustain required technical competence and leadership without good programming skills, staying at the edge and doing prototypes to prove design will work.

And what about design skills? An architect is always researching in some area, looking for future trends and needs of the business he is working for or, generally speaking, "designing for the future". As quoted in a recent Intel presentation about the new 45nm processors technology, the following sentence from Frank Lloyd Wright says it all: "An architect must be a prophet... If he can't see at least ten years ahead, don't call him an architect".

Overall, the course delivers good value and it gives Juval's expertise insight to WCF internals, which is in fact one of this course's assumptions, that is, you'll be using WCF to design your architectures. At the end, I thought the hats I'm used to switch daily made more sense together than before and I felt good. By the way, in IDesign's site there is a video you can watch about all this. Go for it!

Jack Greenfield

- He decided not do do a demo of Web Service Software Factory
 - We can do ourselves that at home
 - We would not get the vision that people at MS is getting
 - It also did not installed correctly on Jack's machine (LOL)

Agenda:
- Learning from other industries
- Mass customisation in software industries
- Supply Chains

- Customer dilemma:
 - A few software vendores build rich but generic platforms (1 million markets of 1 vs 1 market of 1 million)
 - Hundreds of ISVs build industry and/or segment specific products
 - Thousands of SIs customize and integrate
 - Millions of customers use and buy customized products

- Other industries employ mass customisation: automobile industry. If a auto maker shuts down can bring down an entire economy.
- The number of possible variants of what combinations we can get in assembly parts of a car are about 10 to 13.
- On average no more than a handful of cars are assembled with exactly the same features in a year

- Why cant we do this with software? The main reason is that we dont have software supply chains.

- Supply chains:
 - Different suppliers take different approaches to development
  - There are different ways of defining requirements
  - Different ways of partitioning systems into components
  - Different ways of using platform technologies
  - Different ways of deplying system components onto platform technologies
  - Different ways of testing system components
  - Different ways os customising system features
 - Different approaches make it hard to integrate their products to create solutions
  - Hard to verify solutions assembled across multiple suppliers
  - Hard to determine impact of changes in requirements
  - Hard to determine what customisations were made for a specific customer
  - Hard to migrate customisations to new versions of the solutions
  - Hard to coordinate activities to deliver their solutions

- Mass customisation in software development:
 - The road to mass customisation
  - Industrialize development using software factories
  - The only way of a component to be reusable is when we can predict its future. Example: a database.
  - When we know about social circunstances, etc. we can make better predictions
  - Form supply chains using aligned suppliers
  - Mass customise using globally optimized supply chains
 - Industrialize Development
  - Model key work products, processes and assets
  - Accelerate development with model driven tools and other resources
  - Develop solutions by assembly and customisation. This has been ugly, but possible.

- Software factories view is just a way of presenting this problem and the possible solutions. It is not a solution in itself, like Visual Studio designers. They are an instatiation of the view of software factories.

- Publish Factory Metadata
 - Opaque Suppliers vs Suppliers As Services
 - Opaque: different suppliers use different services and there is no easy way to share factory metadata
 - Services: standardization externally facing processes and artifacts. Publish metadata using services.

- Misaligned Suppliers vs Aligned Suppliers
 - From factories to Supply Chains
  - Factories develop tools and process
  - Factories uses Requirements
  - A Factory can generate other factories
 - Horizontal partitioning
  - Separate factory and product development
  - Outsource product development using factories developed in-house
   - Example: A factory built by Big Vendor is used by an offshores services company
  - Use factories supplied by a third party to develop products in-house
   - Example: Finantial Services Firm uses a factory built by Big Vendor
 - Vertical Partitioning
  - Partition factory development
  - Purchase assets from upstream suppliers
   - Example: Finantial Services Firm uses assets from CRM Vendor
  - Sell assets to downstream suppliers
   - Example: Finantial Services Firm supplies assets to (...)
  - CReates B2B relationships when assets are servi based
   - Example: suppliers deliver stubs to hosted services not embedded components
 - Local optimization creates bottlenecks
 - Suppliers respond individually as changes propagate

- Architectural factories:
 - Collaboration factory uses Workflow factory
 - Portal factory uses Content Factory
 - Collaboration factory specializes Portal factory

- Prerequisites:
 - Feature-based requirements engineering
  - Required for reasoning about variability and inter-dependencies among requirements
 - Unambiguous architecture specification
  - Required for systematic development by assembly with adaptation
 - Maturation of service oriented technologies
  - Required for reasoning about operational qualities (...)

- Homework:
 - Are you a supplier, consumer or both?
 - Do you form part of a supply chain today?
 - Or have your software integrated by others?
 - What would it make it easier or what changes would be needed?

The Role of An Architect

- Check "Developing the Future" whitepaper. There is also a Microsoft response to it.
- There is going to be a DTF version 2

- Why having focus groups like this in conferences?
 - The role of an architect could benefit from clarity
 - We had great feedback from previous events

- What marks out an architect?
 - Strong technical foundation
 - Domain Expertise
 - Proven practical experience
 - Very broad range of concerns (technical, legal, ergonomics, business, management)

- "An architect generally is also a librarian". He must know of a wide range of subjects.

- Role of an architect
 - To convert client requirements into solutions
  - Understand the business domain
  - Understand the technology domains
 - To design solutions
 - To advocate solutions
 - To bear -ultimate?- responsability for value and costs
 - To manage specialists
 - Whole lifecycle concerns
 - Strategic
- Types of architect
 - The town planners
  - Enterprise architect
  - Strategic architect
 - The house-builders
  - Solutions architect
  - Applications architect
 - Utility providers
  - Network architect
  - Security architect
- "Every company that has a security architect is in danger of all other people saying that security is not my problem anymore".

- Favorite architect title found so far is: "Food architect".

- Other differentiators are:
- Type of Employer:
 - Corporate
 - Consultancy
 - Product Vendor
- Size of Employer:
 - Global
 - National
 - SME

- How do you become an architect?
 - University course?
  - Not essential (will this assertion be suitable for infrastructure architects?)
  - Not specifally sought by business
  - Focus on transferrable skills rather then vocational skills
 - Become recognized as one
 - Experience
  - Learn from experience
  - Learn from a mentor

- Professionalization of architects
 - Been an issue for many years with little progress
 - Could be driven by:
  - Insurance companies
  - Clients' hiring approach
  - Risk management legislation
 - No obvious national certification body
 - Would need levels of certification
 - Would need "conversion" of existing architects

- The problems of analogy
 - We are like RIBA architects, but not the same
 - Our concerns are like other engineering professions, but not the same
 - Perhaps we lack the confidence to celebrate our uniqueness
 - Are we more like the film industry than civil engineering?
 - "Our role is not to be a bridge but to be a zip". Hmm...

Ron Jacobs, Microsoft, Architect Evangelist

http:// arcast.net (or) www.arcast.tv for video
http://ronjacobs.com

- What is the role of the architect?
- What is software architecture?
- Do I want to become an architect?

- Architecture as a profession
 - 1857, New York, 13 powerful man wanted to elevate architecture to a profession

- The role of the architect
 - Explorer: Colombo. The silk road has gone and there was a need to get goods from the East. Columbus was an optimist. He estimated the distance to get there by a factor of minus 5. He also believed he established a route to Asia but he really got a route to America
 - Architects must help business find technological solutions to pressing problems
 - Explorers are visionary, persuasive and accountable
 - What are the top 3 new technology trends that will impact your organization in the next 2 years?
 - How could these trends be used as a competitive advantage for your organization?
 - Colombo was very persuasive. He tried during 10 years to get help for the mission.
 - What are your projects for benefit to the organization?
 - What evidence or metrics could you produce to demonstrate that the exploration was a success?

Video: Architect as an explorer, or... how Ron Jacobs got Microsoft to pay him a trip to Malibu Beach... :-)

- An architect must advocate his causes. Some explanations using real law cases (O. J. Simpson).

- The lawyer in his role as an advocate is very similar to the role of an architect to his clients. He has to know the client business and needs. He has to represent them an an advocate.

- The first thing a advocate must do is: listen. He must enter the client domain. Understand resources, needs, unique challenges, preferences and business climate.
- Second: he must observe. The Art Of Observing. Check "The Software Architect Profession, by Marc and Laura Sewell". He should follow the all existing process once before starting the design. A failure to observe means millions spend to have nothing in production. A very important thing is to have the user cooperation with the implementation. The architect must design by walking around. The trained eye of an architect should identify impossible implementations.
- Third: he must think strategically. The Art Of Strategy. All businesses should have a strategy of how they intend to win. An advocate sometimes has to stand again its client, saying that is impossible to do/succeed.

- An architect must be a designer. Frank Lloyd Wright believed that humanity should be central to all design. He practiced what is called organic architecture.

- A structure must exhibit the 3 qualities of firmitas (strength, utility and beauty).

- Designers must understand engineering (strength)
- Designers must be able to translate user needs into functional structures (utility)
- Designers must be able to create a solution that is pleasing to the eye (beauty)

- We are only done with the goal when people recognize the value and utility of our work. People have to like it.

- Architecture as the Product of Design

- We still havent found a way of doing good software architecture
- Architecture is an ideia, a plan about what the solution that will be built.
- Your job is to create an architecture that will meet the need
- To collaborate effectively you will need to communicate the architecture to different audiences using a variety of tools, media and means

- Maybe the best quality of an architect is that he is a great communicator: he must talk to and make very different people agree

- We must solve the right problem. Requirements are the way we define the problem we are trying to solve. Most people start wondering in different directions because they are not focused on the problem. This is why it is so important so make the problem clear to anyone.

- Constraints limit the solution (...)

- How good is the solution? Must perform well, be secure, be robust and easily managed, but generally these features are not considered functional requirements.

- Resources include people, technology, legacy systems, technical know-how, etc.

- Sometimes the solution found cant be beautiful. Above all, it must be useful to people.

- Becoming an architect is a journey toward becoming one who dreams of the solution rather than the one who builds it. Architects live in a higher abstraction level and are happy with that. When you are flying you cant see the details which are on the ground but you have the higher view that people on the gorund does not. It is a matter of perspective.

- The question that we should be asking most of the time is not if we can built like that it but if we should built like that.

- Microsoft Certified Architect Certification is like "we dont know what it takes to become an architect, but we'll know when we see one" :-)

Steve Plank, Microsoft, splank@microsoft.com

- Players:
 - Identity Provider
 - Relying Party
 - Subject
- Specs:
 - WS-Policy
 - WS-MEX
 - WS-Security Policy
 - Ws-Security
- Relying Parties can be web services or web sites but usually are web sites
- Using web services makes things more flexible, we could use a WPF application as a relying

party, for example
- An Identity Selector gives:
 - Consistent User Experience: there is no dodgy warnings on the internet
 - CardSpace runs in a separate desktop with no API access, we can not use SendKeys to

interact with it
 - Opening CardSpace is like opening your wallet, you'll imediately recognize it
- Version 2 of CS will have the possibility of having our custom authentication mechanisms
- There is an Open Source Identity Selector
- There is an implementation for Firefox on Windows
- Red Hat has an Identity Selector as well
- Someone did an Identity Selector for Safari
- There is a project from IBM
- Check IdentityBlog for details
- But... the problem is that all those Identity Selector are looking different so the user

experience advantage is beeing lost considering all those different implementations
- For version 2 of CardSpace there will be a layer abstracting the communications between the

identity selector (CardSpace interface) and the card store. This way will be possible to save

cards in USB, use an external web service. This will allow to use a phone number to get a card,

for example. Other example will be to use the phone itself as a card store (!)

Questions:

- Q: Does it makes sense to integrate all those implementations around in one single system at the

enterprise (OpenID, CardSpace, Shibolet, Liberty Alliance, etc)?
- A: It seems to make sense abstracting the identity authentication process in a module that maps

requests according to their formats (open ID, WS-Trust, Shibolet, etc.) because many decisions at

this time are driven by politics and having this module basing a custom STS could be a way of

ensuring the possibility of future easy replacement and extension

- Q: What about mixed environments, like supporting CardSpace and at same time username and

passaword?
- A: There are already real implementations supporting both mechanisms. Just have an additional

column in the database to support both, issue in the same way (see http://www.otco.de). In the not

so near future maybe we will see that using username and password will get so old fashioned that

sites will start to use only cards.

Summary:

- Identity System 1.0:
 - Runs on .NET 3.0 on XPSP2, Vista, next Windows Server
 - Can have Identity Providers on .NET 3.0/Windows Server, using WCF
 - Relying parties can be using Web Services implemented with .NET 3.0/WCF, check sample

Token_Process.cs on cardspace.netfx.com

- ADFS2 (released next year, with next Windows Server):
 - Identity Provider built-in support
 - Cards provisioning

- CardSpace 2:
 - Portable STS, Token Store on the phone and Identity Selector on the Phone
 - Identity Providers will support named values and transactions