IT and business alignment can be challenging. The document discusses how IT is often seen as needing to better support or align with business, but this view is outdated. IT should not focus on aligning but rather enabling new ways for business through technologies like online services, mobile devices, and cloud computing. The key is separating business from IT - business should describe requirements without technical details, and IT should execute without understanding the business domain. Architectures should get business out of IT so they are unrelated and IT becomes an infrastructural facility that business uses without needing to align.

1. Business and IT
alignment
how to escape from
the sand-trap
Pierfranco Ferronato
Project Leader and founder at Soluta.Net

2. What we see
• We are here because we perceive an issue with IT
• We perceive that IT needs to support business "better"
• We see that Business runs faster then IT
• We see that Business is bound to IT and makes things slow
• We understand that IT is struggling to support Business
• Business is asking IT about how they do stuff

3. Why are we struggling?
• Software maintenance costs 90% of the total cost in 10 years
• 10% is the first release, 90% is maintenance
• Maintenance takes time because software lives
• but shall not cost 90%
• Software lives because it support the business and the
business runs!
• Building vs maintenance
• Civil vs Software engineering
• Concentrate in earlies release or reduce cost
• Design for change is more complex

4. What we look for
• We are here to look for a
"better" way
• We see that modelling is a
helping hand
• Separate design from requirements
• Separate technology from functionalities
• You are often told to
"Align IT with the Business"
to find your way out
• It's not as simple

5. IT can be a Business enabler
• IT can create new way to make the Business
• On line services, Mobile devices,
• Pervasiveness, Cloud
• IT can open up new ways
• IT can give the Business new horizons
• Assuming that there is a gap to close, gives the false
perception that IT is "behind" the Business, chasing it
• IT has not simply the goal to align with the business because it
can pull the Business
• The IT is running the Business
• No Business can reasonably be conducted without the support
of IT.

6. Business Virtual Machine
• IT has to run the Business
• But this Virtual Business Machine need to have nothing inside
about Business
• You describe the business and give it to IT for execution

7. IT as it is
• I know of developers knowing the business more then the
business itself
• Business is buried in the code
• I can hear Business people asking the developers "how do we
charge the business customer for rate A?"
• And realize they have to look at the code to reply!
• IT has not to talk business
• Shall look for an architectural style that GETS THE BUSINESS
OUT OF THE IT!

8. Business as it is
• How many times I can ear the business saying
• "we need another table script to update the pricing schema..."
• „we need a foreign key from agent table to agency table because
we have to trace for which agency the agent is working“
• Please stop talking about IT!
• Tables, string, SQL, scripts, DB, threads, servers...
• Business people has to be trained not to care about IT

9. Align IT with the Business?
• Definition of IT? Which role do we expect?
• It's already a legacy perception of IT
• It's more complex than that
• Get rid of the gap
• Because there has not to be a gap
• Business and IT need to be UNRELATED

10. Forseen role of IT
• The IT becomes infrastructural
• a facility you can swap out/in
• The business is IN the company and NOT in the IT
• No need to align!

11. A WORD ABOUT ARCHITECTURE
The four architectures viewpoint, from RM-ODP
BusinessProcess

12. Architectural Viewpoints
BusinessProcesses

13. Application Architecture
BusinessProcesses

14. Application Architecture
Principles
BusinessProcesses

15. Technical Architecture

16. Functional Architecture
BusinessProcesses
The Functional Architecture decomposes the functional requirements in
consistent models:

17. Management Architecture
BusinessProcesses
The Management Architecture defines the Project-wide governance
needed to release the system under the agreed contract's terms

18. Architecture Viewpoints
Summary
BusinessProcesses
18

19. BUSINESS PROCESS PROJETS
Manifesto and approach
BusinessProcess

20. Methods Stack
BusinessProcess

21. Business Processes
statements
BusinessProcess

22. Project Life-cycle, draft
BusinessProcess

23. Roles (TBD)
• Business Domain Expert, reference with stakeholder
• Business Analyst, Functional Architect, bridge problem with
solution domain
• Solution Architect (Application and Structural Architect)
• Developers
• GUI, script
• SOA dedicated integration team
• Test
• Deploy, production

24. Metrics
• Define SLA
• Map time with cost
• Define threasholds
• Measure AS-IS
• BAM
• Monitor threashold
• Functional and techinical
• Measure and compare
• Tune and redeploy
BusinessProcess

25. BPM Projects based
Principles
• BPMN need to model only the Business
• Factor out integration solutions, GUI, DBMS
• Extract Business Rules, make them live in the model
• Adopt a Design Pattern to have consistent models across the
organization
• They need to show the same «approach»
• Maintains a Model Repository
• Be the prime contact point for maintenance/reengineering
BusinessProcess

26. Process Modelling
Anti-pattern
• Spaghetti model
• Modelling without methodology or architecture
•  maintenance becomes expensive
•  does not scale functionally
• Sopravvalutare il ruolo dello strumento
• Dimenticare factory process, coordinazione
• Buy an expensive UML tools, use it, blame it, forget it
•  Riduce il ritorno dell’investimento
• Notazione errata
• Modellare con una notazione workflow
•  il modello non rispecchia l’organizzazione
• Modellare l’integrazione tra i sistemi (EAI) e non i Processi di Business
• Manutenzione tecnica e non di processo, out-of-scope, inutile
• Modellare sulla base degli Use Case
• Vincolante, over killing
•  manutenzione eccessiva
• Non scomporre in sotto-processi
•  basso livello di riuso
• Non di immediata comprensione
BusinessProcess

27. Agile Modelling Architecture
• The practises of founding the software factory using modelling
practice that consider a model the atomic artifact to be
executed

28. SUCCESS STORIES
By Pierfranco Ferronato
BusinessProcess

29. IMAGO
• Per Telecom Italia DRE Spa [1997-1998]
• Capo progetto, team leader
• Realizzare uno strumento CASE che supporti la metodologia di
CSELT (IMAGO) per la modellazione organizzativa ed operativa
dell’impresa
• Mappe di contesto
• Organizzazione
• Processi
• Attività
BusinessProcess

30. Pant@
• Per Coopservice [2005-2006]
• Capo progetto, Architetto
• Supportare i processi aziendali con approccio BPMN ed MDA
BusinessProcess

31. Sanità Elettronica
• Innovazione Italia Spa, TSE [2005-2006]
• Architetto
• Architettura model driven, repository dei processi sanitari
BusinessProcess

32. Pierfranco Ferronato
Soluta.Net
mobile: +39.348.071.4898
skype: pferronatosn
Graphical contributions from
Sue Maurizio, healingdream, jscreationzs, M. Bartosch,
Felixco Inc. e Michelle Meiklejohn