|
|
La formazione, come anche i servizi a valore aggiunto, devono poter innalzare lo spirito permettendo di aggiungere a ciò che si impara un atto solidale verso Persone che forse non hanno neanche il diritto all’istruzione.
E’ per questo che abbiamo concepito questo modello di Formazione 2.0, dove il due punto zero significa proprio quell’interesse e quella passione che si ha per gli altri. E’ per noi molto importante riuscire a rendervi partecipi dei nostri progetti e del nostro modo di pensare e di vivere un ambito formativo dove, assieme agli aspetti innovativi che le lezioni portano e agli aspetti sociali che le nostre aule vanno a costruire con esercizi di gruppo, aggiungiamo questa forma di altruismo, delegandola a tutti i discenti.
Come funziona? Il nostro modello di formazione solidale funziona come descritto nella sezione specifica (http://www.mondora.com/training-commercial-offer/).
La nostra riconoscenza è la vostra riconoscenza verso un ambito sociale di vostra scelta e lasciamo a voi l’atto di donare a una o più Associazioni non a scopo di lucro.
Interaction design is a technique improving the web usability and user centered design to identify what is really need in a 2.0 online service and what can be forgot. In our tangible word this is already done by who’s marketing goods and who’s facing the customer directly. I’m thinking about Starbucks that sells coffee in a really good fashion or UPS that is facing customer with a professional front end. Starbuck’s and UPS’s employees are the direct face of the company to the customer, and they are a mix of professionalism and marketing. They know exactly what to wear, what to say, and how to make comfortable a situation with a customer.
This is coming into the Web Space, and has been discussed a lot at the Web 2.0 Expo in New York last week. The web 2.0 is improving with interaction design that focuses on doing only what a company is thought for and on forgiving extra services discoverable on the market. Interaction Design from Joshua Porter is the first step in this scenario, and now Christopher Fahey from Behavior Design is talking about Seductive Design where 2.0 services seduce the end user.
I think that is on top of the interactive design’s principle from Porter, and it is introducing some marketing concepts in software development. In classical corporate marketing focus is to make some corporate services appealing and sexy. The same is happening with the ideas in seductive design where the focus is to create a seductive interaction with the user mixing images, videos, and behaviors. This with style and creating the desire and then pleasure that the service is creating. Services user experience is an emotion for users that are paying for a system. Everything is thought as potentially something new; the way to attract, to create suspense and to delivers a service in a professional way trusting who’s at the counter side. Imagine a future’s Apple product, is it in your imagination an unusable product, with bad colors and high price? That’s because Apple has created a Product Service Factory that innovates in a real and sexy way.
All this is coming with Seductive design where marketing is becoming a cross culture like software development is crossing to all the roles.
Services will attract more users more they’re sexy, and users stay with the provider for the quality of the service and for the trustiness that the company has created.
 Design has become popular in several context, and it is applied in applied arts, engineering, architecture, and other creative endeavors. Design is something cross to all the things around, and a good design is simply perceived without too much understanding going straight through the final objective.
Last years I did lot of things spacing from developing, architect, designing software to put customer ideas to market and I’ve learned lot of things about each activity I performed: for an excellent result every activity should have a good style and a good design. But, what a good style and a good result? To fast figure it out, if we think a picture of a car from a kid and from a designer like Giugiaro, they’re, both, drawing a car with four wheels, and engine, some seats etc., but the main difference is that Giugiaro’s car will seem more accurate and beautiful that the kid one. That’s only because Giugiaro is a professional designer and the kid is just playing with a pencil and a sheet. Now, switching the metaphor back to everything we delivered in the past we can focus on the result and on the next improvement in term of style. Here is a list of key point when I’m doing things trying to figure out “a style”:
- Build only what is absolutely necessary
There is lot to do and if we do more than our potential, maybe we’ll reach the goals, but lacking on style and quality. So, one of the first statement, when I approach something is to find out what cannot be done to stay focused on small portion and put all the energies there. This trend is notable in 2.0 where services focuses only on small things giving an idea of lightness and the refinement process improves iteration over iteration.
- Quickly turn beginning users into intermediate
Think about a sexy girl! She creates interest without telling things; the viewer is not reading papers, documentation or watching podcast to be attracted by the girl. She is turning a beginner user to an intermediate fast creating the correct interest in doing things and maintaining the learning curve small. This is what in Agile Development, we call self documenting software: if it is sexy and appealing for developers can be learned fast without too much archetypes around: like a sexy girl.
- Prevent errors whenever possible and handle the errors we cannot prevent gracefully
Good style is something appreciable outside the designer and style should be perceived rapidly. You can get wrong while designing, this is why on every small increment the heart of design should pulse to his target to check if it is good for it or not. It is not a way to pre-sell, it’s a way to anticipate problems gracefully. Shouting every small iteration makes a good style growing.
- Reduce and refine interactions and task flows until even the most complicated applications are clear and understandable
Refinement focuses on making things implicitly clear, in the way just watching them for few times, they’re understandable. This is what I do, when I seek what cannot be done. This is not a technique to postpone work; it is a method to check if something is still available and need to emerge from the already available resources. Good style is made of few things because the huge variety of things is gone implicitly inside the design itself and is easily discoverable and understandable.
- Adopt metaphors, better visual metaphors to explain the complexity and bring it to a human comprehensible level
Metaphors are the key to find out what is implicit in a context, and only with metaphors you can focus on what is really not clear. When thinking an archetypes a metaphor is a good statement to better understands, picture or diagram the archetype itself.
- Ignore the demand of users and stick to a vision
Improvements are done through brainstorming and brainstorming should be stick to a vision, a common vision. It’s important to stay focused on the purpose, and not to switch over ideas every user express.
These are only a bunch of rules; I’m learning from my experience. Surely some new rule can come in the next future.
 The main intent of the Software Development As A Service, is to outsource development to stay better focused on what is really producing value in the starting 2.0 pioneer’s company.
A fresh and new idea is the real trouble of a Startup and most of the energy should be spent on that direction, while other problems are addressed trusting the services bought depending on the Service Level Agreement defined.
After a good experience in the 2.0 era in developing several online communities from the Service Provider point of view, I think it’s time to share what I’m learning and the mistakes I’m doing in facing this kind of opportunities.
I’m calling those experience anti patterns because they are a good representation of what can be optimal in theory and is really ineffective in practice if the 1.0 culture is mixed with the 2.0 culture.
Embrace Software Development Company processes
Having the idea to implement all the software by delegating to a Development Provider, comprises the adoption of all IT culture of the engaged service provider.
This can be obvious a really proficient until the Startup Company is trying to figure its own development process asking the service provider to embrace and focus on its way of doing things.
This approach drives to two main drawbacks:
1. Startup company is now focusing ideas to development process that is not really creating revenue for its business;
2. Software development company is forced to change the way they do things, learning a new option in software development and focusing on the customer’s process intention instead of customer business needs.
This moves the Startup’s focus from the Business idea to development spending energy (and money) in thinking on gates instead of thinking on the time to market for even easier idea and Software development to produce process’s artifacts (reports, well-formatted documents, etc.) instead of good software.
Focus cannot be easily restored because the current focus is to be compliant with the process. When choosing a Software Provider Company, a 2.0 startup should put in its decision table.
The way the provider works is a good point of evaluation and must be agreed with the Startup Company to avoid the process as the next collaboration’s problem.
Identify a Service Level Agreement on each Service
Startup and Service providers should agree on both parties on how they’re allocating or delivering services request.
A Startup Company should create milestones that bases the professional relation. Milestones are business objectives that potentially influences the ROI of the Startup Company, and Servicing company should base their SLA depending on the milestones objective.
A SLA identifies an interaction model where parties agrees to implement something that is really valuable; this creates a conversational and honest model where things go in the same direction and both.
The parties are focused on the goal. Without a SLA, a Startup Company is shifting to an investment protection system paradigm where energy are spent to avoid money loss. Without a SLA, a Service Provider focuses on service’s accountability instead of service providing.
The more the Service Level is the more is the price for it. This simple rule can be extended in: the more on the service level of what is really indispensable the more a company can pay for it.
Easiness is not simpleness
A 2.0 application is a big mash up of Services around the network; in the 1.0 culture there is the idea of System Integrator that is responsible solely to do a kind of component integration.
Meanwhile in the 2.0 culture the idea of system integrator is hidden by the idea that services are available on standard protocol and then easy to integrate because it’s just a javascript call or a bunch of ruby on rails lines.
The complexity of integration in 2.0 is the same of the 1.0, every integrated platform must be reliable, must work and have custom development associated. The big difference from 2.0 and 1.0 is that 2.0 integration is through services starting from the presentation tier, while in the 1.0 everything is hidden in the integration tier.
A 2.0 approach is to make the user interaction easier by leveraging on all the available technology: that’s really complex and require great skill and good professionalism.
Re-DO to DO approach: talk and listen together
2.0 culture is pioneering, and fresh ideas are often not clear to be written as a strict requisite. It’s easy to misunderstand what the customer is explaining and what the Service Provider is understanding.
Small iterations and a continuous conversational approach must be established to achieve the same goal. Customer and Service Provider have to thing that the counterparts are producing value day by day discovering things that are still unknown.
A 1.0 approach drives the customer to outline all the requirements predicting what will be, and in the most cases failing in some aspects. Failing means: redo the same thing. Consequences of the “redoing mindset” will be unable to launch the Startup’s Services at each milestone. Redoing several times, breaks trustiness and team happiness.
A 2.0 approach is based on continuous improvement on things and from the failing paradigm moves to the Learning paradigm. Continuous improvement switch the mindset from stable services to perpetual beta services.
Conclusions
These are some of the things I’ve found from a first retrospective with all the involved players in my experience from the Provider Company. I’m sure this is only a starting point for the 2.0 anti pattern catalog and more will come from the experience.
 Architectures are following the way to be extensible, flexible, and easy to be maintained. A 2.0 scenario makes things growing on demand, starting with a small set of features and growing to a huge application with lots of other integrated application (mashup) and complex business logic. Everything shall evolve and redesigned time over time, feature over feature.
The best approach in delivering a modern application is to consider the application itself as a big mashup of the application. This implies, again, a multi-tier approach where there is something in the middle tier that executes something valuable and there’s something in the presentation tier that orchestrates business behavior.
Thinking in the way we thought with Enterprise architecture based on EJB and other complex solution, the separation was into the presentation tier, the business tier, and the integration tier.
All the components should be divided into one of the above tears, depending on their roles, and responsibility inside the architecture. Why the separation of roles? Separation of roles can tune the architecture in several point with lots of combination. By implementing modern architecture on social communities, I’ve found important in differentiating the business tier from the presentation tier: as I do in enterprise architecture with high available technologies. Things and names changes, but the result from the architecture should be the same: having and extendable and flexible system.
 The key concept in modern thinking is to separate services their API from their “social interaction” promoting a Widget as a visual coordinator of something is happening backward.
This brings out a reusable API, a first use of the API that is the Social Application and the versatility of the architecture. Having modern API exposed in several formats including JSON restful services, this enabled the idea on having the integration tier as the “presentation tier” or on the old fashioned presentation tier. The modern presentation tier is called Mash up and is really adaptable depending on the needs. If it is required that a machine should do something on the integrated platform (viz. flickr), it can be done at server-side as a restful service. If it is required to operate with some integrated platform visually, it can be called directly from the presentation tier. Yes, this is the first example of how flexible can be an architecture: I can choose to do integration on throttling on the service platform or to choose to go strike through the integrated platform directly from the client interface. This is gained only because, the integrated platform has been tough having the concept of API and that the Social Application is itself a big mash up of those interfaces. Making an API public or private is a tremendous business decision, and should be accurately agreed after heavy consideration. Having a public API makes other the reuse idea instead of the feature copy idea; this requires the company, should also have a clear policy on how integrators can use its API for their mash up. This will be a next big opportunity that 2.0 will create. Stay tuned.
 Usability has evolved in practices like interaction design, social design an others. An architecture should evolve with the system letting mash up to be easily created, managed and removed. This is a way when thinking architecture an architect should take care that one principle of the architecture should be hackable. By hackable I mean do things in a “informal” way, where mash up or enterprise’s mash up are activating architecture blocks.
Internet has become a great place where people exchange data and interact to evolving work in an efficient way. Interaction design, usability, and other disciplines are discovering a pattern to make applications people centered. This kind of approach is even more driving software conception having people in mind instead of technology and technology is the facilitator tool to address this kind of approach.
Software architecture and Interaction design fits together and melt as needs. Re-usability is required not only thinking on architectures even thinking on people that are using the system too.
Architecture and component interaction is typically forced by Use Cases and is not so flexible to adapt different evolving usages of the system. Architectures should be hackable to adapt user needs.
Hackability of a components includes several point of view:
- business view: what business feature can be reused by a component;
- calling view: which protocol is exposed by this component, and how can be called by mash up
- context living: how do a component fits in a context while collaborating and in other context when reused, who declares it and how?
Sense is promoting the concept that a Service is everything inside a physical and logical architecture: components, frameworks, machines, application server etc. are services.
Sense’s services can be exposed over several protocols including http (xml-rpc), http (json), iiop, jms. From the protocol point of view, Sense lets services to be in some mash up; it doesn’t matter whether the mash up is at client side or server side. Service’s context before and after invocation is updated in Sense by the application of crosscutting concern that is intercepting a call to a service in a particular context and are enriching the incoming and out coming call with context specific information. This is gotten through the definition and the application of Emotions that are though as aspect that crosscut in an architecture.
Scrum is a self-managing techniques that help software to be packaged iteration over iteration over a set of business critical feature. The iteration approach suites well to implement and release bunch of feature ready to be launched to the market. In mondora we focus on a Perpetual ß tool that helps us in finding and maintains the right path for the goal.
In mondora we’re working with Scrum for several years, and we find it useful to log and organize on a sheet: the process, the actors and the things produced iteration over iteration. This helps me and all parties during the development how us in mondora are approaching industrial software development: in a really open way.
The archetypes we produce are refined iteration over iteration; for example, while discussing the Sprint at the Sprint Planning meeting we try to figure out how the next feature implementation will fit on an architecture and we will produce some architectural document.
A set of feature is committed for a sprint, and the industrial approach stages directly the alfa version during development time. Because we’re working on features, we’re focusing on statement that creates value and at the end of a Sprint we’re ready to launch them as a Beta feature.
This happens iteration over iteration.
This only because Agile focuses on the idea that everything in a sprint is “something potentially shippable.” We then stage the next sprint and fix all the bugs in the prior consolidating those beta services as stable services and releasing new beta services.
This happens Iteration over iteration.
Every time, every day we’re looking at our Perpetual ß scrum sheet tool to know how, what e who is involved in the process and which will be the delivery. Of course, our tool is in ß too, and is growing day by day.
Tool is available to download here: mondora-perpetual-beta-scrum
Nowadays companies are thinking to promote a social graph inside the corporate instead of hierarchies. This is common to agile practice where all the developers together are the project manager.
Agile Manifesto and 2.0 approach have something that sounds really similar: people. People are the key in both Agile and in Enterprise 2.0.
Agile Manifesto outlines how project will be managed in a more conversational way, where values are the driver in software development. An enterprise 2.0 is focusing on people too, where a company’s seen as a multitude of people that are working together, having a relationship that helps the system growing.
 Currently companies are focusing on process and tools over comprehensive documentation. Currently companies are following a plan that enables negotiation between Customer and Provider.
Agile shall make companies focusing on individuals and interactions. Agile focuses on working software that is responding to changes. Agile establishes Customer as a Partner through collaboration.
 The enterprise 2.0 shall make companies focusing on relations between individuals and interaction over essential documentation and a fully functional company. The Enterprise 2.0 is responding to change and establishes Customer as a partner and colleague as a Friend.
Enterprise 2.0 focuses on adopting similar values expressed by the Agile Manifesto to corporate where the delivery is the corporate itself and not only software. Corporate, like Agile management techniques, trusts on human ability to create and maintain hi-value relations.
Both of the two mentioned approaches create a more conversational environment where colleagues/developers/partners can share their opinion their problem each other. Informal relations are brought forward to formal relation, where the main opportunity is to evolve something together.
Today, online services are in perpetual beta since years and it sounds a bit strange for an engineer that delivers software.
I mention Flickr for example that has been in beta for several years.
Going deeper on why perpetual beta and not stable release, I see the way software is implemented is changing. Developing over small iteration requires to split software into feature and components into services: smaller is the iteration (1-5 days) more is the dependency to a service crafting approach where services crosscuts around the architecture by improving the architecture. Small iteration produces few lines of code then small bugs, and test is shortened too. This makes the software to change frequently by increasing stable services and beta services over time.
Development to production small iteration approach gains lots of benefits like:
- rapid return of investment;
- rapid change when competitors launch the same service;
- user centric needs;
- rapid solve possible bottleneck with short downtime;
- rapid scaling on business continually iterating over new functionality.
This type of approach is making previous 3-4 iterations stable and well tested and the other still in beta because they’re really in beta.
Adopting short iterations, requires a new mindset in achieving Software Architecture: SOA is an example where what is implemented is Software broken into Services that implements features.
This means beta is for feature.
This means that business feature is still in beta, and consolidates over time when users thinks they’re stable.
Flickr is again an example.
It has been qualified as beta for several years and this is the approach of big ventures that are delivering feature iteration over iteration investing money iteration over iteration and driving behavior over user requirements. In facts, to organize what service will be the next released service, Flickr and the other players are creating communities of users that evaluated and propose new behavior discussing on it.
This is why modern web site are proud to declare “beta” for 2 or 3 years and to move to “gamma” after 4 years.
It is more a business practice than a software practice.
I’ll continue this topic by drilling down my mind map to focus better on how SOA, Virtualization, Agile are related.
Stay in touch!
Developers are building sophisticated tagging system, clouds and drill down mechanism to explore them that project their service in a 2.0 scenario.
Tagging is implemented because it gives lots of benefit in managing and finding contents. Developers should gain this benefits directly from the technology they implement while developing an application.
For example consider if you’re writing an application module that consist of:
- a web page
- a javascript file
- a controller object
Tagging them with a tag like module: bookmarklet a developer can consistently declare a unit of development and group logical information together.
Tagging evolves an architect by letting a user to perceive an application in several form. If two files are tagged with an architectural block like the previous block, an extra information can be derived: those two components have a relationship and this relationship should be preserved.
Evolution of a tag cloud
Tag clouds are an impressive way to show which is the major taxonomy on a given content. In my Developer 2.0 idea, tag cloud could be a starting point to get information about how software is implemented and the ranking of each tag is derived, as in the common way, from the tagged contents (sources, documents, etc.).
Filtering tags on a tag cloud gave having a specific namespace, should catch immediately which is the most complex behavior of the system in terms of number of artifacts in it.
In a tag cloud like this, tag names should be arranged by thinking the idea that a content is a neighbor to another content if they share the same tag. All those two content have different tags on and depending on their neighborhood they are showed near by on the tag cloud.
Imagine if you like to browse a tag cloud filtering for namespace: architecture:
Cloud is composed of:
architecture:payment
architecture:messaging
etc.
If a specified payment component notifies troughs the messaging platform a transaction completion, it is tagged by the developer both as “architecture: payment” and “architecture: messaging.” Those two tags are now neighbors and in a tag cloud they will be showed, or better linked with their specific size.
This is a new, modern way to have a diagram of how an architecture evolves and the tag cloud can be computed over time and this is a great opportunity a tagging system in the developer 2.0 environment introduces.
I’ll continue in the next posts, about how tagging can help me – as a developer – in doing better.
|
|
|
Comments (0)