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 pulling 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 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 dye. 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 to SO.

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

Steve Plank, Identity Architect, Microsoft

- Federation Flow
- Home-round discovery is the process of knowing of all the trust relations I have which one will

be the one that applies to me
- All the redirection is done using HTTP 302
- Check the WS-Federation Passive Requestor *Interoperable* Profile protocol, lastest version is

of 2006
- ADFS Limitations:
 - Browser only, no web services
 - Home realm discovery
 - Domain-centric viewpoint
  - All trust deciosions made centrally, one-by-one
  - Doesnt scale; users not involved
- Identity Metasystem Protocols, check www.identityblog.com
- In active federation, the client has the option of looking at the token and aborting it. This is

something that does not happen in passive federation
- Shift of Emphasis
 - The user is in control, home realm discovery is selecting an IP
 - Identity selector, allows the user to select an identity provider and coordinates

protocol flow and user experience
- The identity provider is a web service following standards
- Implementation: X.509, Web and Web Service Protocols
- Windows CardSpace:
 - Easily and safely manage your digital identities
 - Authenticate with web sites and web services
- Is easier:
 - No usernames and passwords
 - Consistent login and registration
- Is safer:
 - Avoid phishes
 - Multi-factor authentication
- The relying party says what IPs will it trust
- Information Cards
 - Signed XML metadata describing an identity provider
- CardSpace and the Enterprise
 - Eventually all MS products will interact with CardSpace
 - ADFS v 2.0 will respond directly to CardSpace requests
 - In about 3 years will be pretty normal to use cards to login
- Key: Trust is local
- When to use cards?
 - Integrated authentication, nothing gets in the way, perfect inside the firewall
 - Information Cards, no username and password, just select a card, explicit security

boundaries
- Future: Dual Architectures?
- ADFS 2
- Conclusion:
 - Information Card architecture provides benefits to the federated enterprise
 - However "User" is in control
 - Simplification and visualization allow IT to devolve control to resource owners
 - Setting access control policy for relying parties becomes simple
 - Ultimately, we reap the benefits of a single user experience at home and in the enterprise

EN01 (II Part)

- Architecture has not the same scope as systems engeneering
- There are similarities with a physical arquitect
- The deliverables make difference, at the end of the day that will be what distinguishes architects

Architects flavors
 - Enterprise
 - Solutions
 - Infrastructure
- Microsoft has met with many university teachers to ask them what do you want to be able to deliver architects to market?
- There are not many real architects *in the world*, what we have is many software and system engineers
- When you start to do implementation you are not doing architecture anymore
- Architecture is about ensuring best practices, about enforcing quality
- Most of best practices are not learnable from school, you have to pass through experience to get it

Matt Deacon, Microsoft UK,
Steven Moxey, Manchester Business School

(Nota: entrei a meio da sessão) 

- What are the key attributes of a traditional software product?

Case study:

SIEBEL (CRM)

- Market share
- In-house retention of data
- Integration with other systems
- Customisation to requirements
- Scalability of system
- Offline capability (smart client)
- Resilience and scalability. Availability, response time
- International deployment
- International support
- Reassurgingly expensive
- Unique information on business
- Industry coverage/process
- Integration with other systems
- Integration with other LOB applications
- Fits to my process - unique business process
- Data ownership

SalesForce.com:

- Reduced barrier to entry (cost)
- Scalability of cost "pay as you grow"
- Access anywhere
- Almost Lower TCO
- Speed
- Automatic upgrade
- Business continuity
- Disaster Recovery
- Customisation limited but easy
- Mash-ups/interface/integration

Key needs from a new market customer perspective:

SMEs:

- Low perceivable costs
- No IT
- Scale with/as business scales
- Training
- Integration out of the box
- Community ecosystem
- Support by the Provider

Arvindra Sehmi, Microsoft EMEA DPE

- This session is about emerging ideias and concepts
- The term Service Capsule is not an official approved or endorsed by Microsoft
- The term Service Capsule is used simply to distinguish from the term Service
- This session is not supported by Microsoft

- Business Processes actors go through different interactions
- We need to know what sequence to use when calling services that perform those actions
- Humans will always be envolved in these workflows
- What kind of business protocols should we use to automate this?
- There is much more to the design of robust systems then good tools
- Business process, knowledge concepts
- A BP consists in coordinating a number of actions or tasks
- A BP generates business knowledge, which is composed of business facts
- Three levels of business automation
 - Coordination
 - Infrastructure
 - Information
- Business roles are supported by information and infrastructure roles
- Services and Workflow, workflow-backed service contracts
- A Windows Workflow sample shows it is possible to model service calls sequence (duh!)
- We can represent the metadata of the workflow as we wish, it could be a BPEL document, SSDL or WS-CL
- A workflow as a service

(Nota: saí antes do fim porque a sessão tornou-se numa introdução ao WF)

Steve Jones, Head of SOA, Capgemini

- There *is* a SOA Reference Model: adopt the OASIS SOA Reference Model
 - Its independent
 - Its an OASIS Standard
 - Its applicable to business and IT services
 (...)
- IT needs to change to be about Value, not Cost
 - Today: 39%/61% (Cost/Revenue)
 - In 3 years: 69%/31%
- IT spend on the old and the new (15%/85%). New is expected to deliver value.
- People and Service interactions: Web 2.0 and SOA as a mechanism to interact
- What this means to SOA? If SOA is to deliver true value then it must:
 - Change the way we support systems, manage systems, modify systems, start with the existing IT estate
 - Claims that SOA sits above legacy are wrong, EAI claimed that and failed, Mainframe systems still continue to be extended, ERPs are acritical parts of IT infrastructures, Small scale applications are divorced from IT, business non-IT functions are divorced from IT
 - Claims that SOA is about technology is bunk, OO was not about C++, Smalltalk or Java
- SOA has to change ALL OF IT! Business, IT, external.
- SOA is about how you think about IT
- SOA has to be about making it simple
- Flexibility is actually a bad control, structure is critical, governance is needed.
- Delivering clear Business Service Architecture means:
 - Aligning your governance to the BSA
 - Including new build and maintenance in a single structure, no more architecture just for "phase 1"
 - Having explicit business ownership of the architecture
 - Continually updating the architecture
 - Doing process second
 - It Impacts all IT, and relationship with the business
- Understand what your IT is woth, and how to deliver. Do not change what is working just why technically will be a great project. Why spend?
- One size does not fits all. We need to understand what size to use and when.
- Projects make monoliths. Do programmes instead.
 - TCO not Cost to Live (CTL)
 - Enables fix and modify cycle to be integrated into development
 - Stops projects accidentaly creating monoliths
 - Keeps fix and modify cycles short
 - Aligns ownership directly to the business, not the project manager
- Apply SOA to support
 - Align your help desks to the services and their value
 - Capture change requests on service lines
 - Organize team leads around the services, not the technology
 - Make architects understand both the old and the new
 - Ensure that systems are continually evolving with the business
 - Stop the "legacy as deployed" problem. Dont try to make everything five nines just because you can. If business says dont care, then dont care. Thats because the value it is not there. Its vital to understand this.
 - Manage the portfolio based on its value
- Summary:
 - SOA cant be about just the new if it is to solve problems
 - IT organizations need to change the way they think
 - IT is changing, old assurances no-longer hold
 - SOA gives a single framework in which to make decisions
 - Adopt the OASIS SOA Reference Model, its a good standard and it has been used very successfully: Its much better then picking a vendors and it is a waste of effort to write your own

Additional reading:

- http://service-architecture.blogspot.com
- Enterprise SOA Adoption Strategies, http://infoq.com/minibooks/enterprise-soa