resumen am

8/11/2019 Resumen AM

1/7

Every system must be built so it can fit into your existing environment, better yet so that it reflect s

the future vision for your organization. This sort of information should be captured in your enterprise

architecture, in current state and future state models respectively. One goal for agile enterprise

architects is to ensure that this happens in an effective manner, to ensure that the needs of the

business stakeholders are understood and anticipated, and to support project teams in their

development efforts.

1. Why Working Together is Currently Hard

The relationship between data professionals and developers is often less than ideal within manyorganizations. Yes, there are some organizations where these two communities work together quitewell but there are always tensions when a healthy tension exists between groups yourorganization can benefit, unfortunately these differences often lead to conflicts that arenthealthy. Your organization may not experience every single problem listed below although it likelysuffers from a subset. The challenges that data professionals and developers must overcome caninclude:

1. Different visions and priorities. Developers are often focused on the specific needs of a

single project and often strive to work as much as possible in isolation from the rest of theorganization. DBAs focus on the database(s) that they are responsible for, oftenprotecting the databases by minimizing changes to the them. Data administrators anddata architects focus on the overall data needs of the enterprise, sometimes to the virtualexclusion of the immediate needs of project teams. Clearly the scope of each group isdifferent, their priorities are different, and the issues that they deal with are different. Tomake matters worse your project stakeholders, including direct users all the way up tosenior management, have varying priorities and visions as well.

2. Over specialization of roles. Specialists have a tendency to become too narrowlyfocused, to know everything there is to know about a small slice of software developmentbut can become oblivious of everything else. It is quite common to find senior Javadevelopers that have never heard aboutdata normalization,or even understand why youwould want to do such a thing, and data architects that cant read a Unifi ed Modeling

Language (UML) state chart diagram. Because they are overly specialized they often havedifficulties relating to other IT professionals. A common agile philosophy is that ITprofessionals should have a general understanding of the overall software process andhave one or more specialties. Because they are generalists they understand the broadrange of issues pertinent to the software game yet at the same time have specific andvaluable skills to offer to their team. People who are just specialists or who are justgeneralists are at the extreme ends of the spectrum, as with most things in life it is far betterto find a sweet spot in between these two extremes. What we really need are people whoaregeneralizing specialists.

3. Process impedance mismatch. One of the few things that processes such asDisciplinedAgile Delivery (DAD),Extreme Programming,Scrum,DSDM, Crystal Clear, andAgileModeling have in common is that they all work in anevolutionary (iterative and incremental)manner. Unfortunately many within the data community still view software development asa serial or near-serial process. Clearly there is an impedance mismatch here, indicating thatthe data community needs to rethink their approach. It is possible to take an evolutionaryapproach to data, a change that will requirecultural and organizational changes within yourorganization.

4. Technology impedance mismatch. Developers work with objects and componentswhereas data professionals work with databases and files. Software engineering principlesform the underlying foundational paradigm for objects and components whereas set theoryforms the underlying foundational paradigm for relational databases (by far the mostpopular database technology). Because the underlying paradigms are different the
http://www.agiledata.org/essays/dataNormalization.htmlhttp://www.agilemodeling.com/essays/generalizingSpecialists.htmhttp://disciplinedagiledelivery.com/http://disciplinedagiledelivery.com/http://www.agilemodeling.com/essays/agileModelingXP.htmhttp://www.implementingscrum.com/http://www.agilemodeling.com/http://www.agilemodeling.com/http://www.agiledata.org/essays/evolutionaryDevelopment.htmlhttp://www.agiledata.org/essays/culturalImpedanceMismatch.htmlhttp://www.agiledata.org/essays/impedanceMismatch.htmlhttp://www.agiledata.org/essays/impedanceMismatch.htmlhttp://www.agiledata.org/essays/impedanceMismatch.htmlhttp://www.agiledata.org/essays/culturalImpedanceMismatch.htmlhttp://www.agiledata.org/essays/evolutionaryDevelopment.htmlhttp://www.agilemodeling.com/http://www.agilemodeling.com/http://www.implementingscrum.com/http://www.agilemodeling.com/essays/agileModelingXP.htmhttp://disciplinedagiledelivery.com/http://disciplinedagiledelivery.com/http://www.agilemodeling.com/essays/generalizingSpecialists.htmhttp://www.agiledata.org/essays/dataNormalization.html


2/7

technologies dont work together perfectly and an impedance mismatch exists. Thismismatch can be overcome although doing so requires a significant skillset.

5. Ossified management. The technology and techniques used by IT professionals changesrapidly, a fact that we all know very well. As people progress up the corporate hierarchythey deal less with technology and more with people issues, the end result being thatmanagers have lost their technical edge. The problem is that their previous developmentexperiences, experiences on which they base technical decisions, may no longer beapplicable. We saw this as an industry when we moved from procedural technologies toobject-oriented technologieswhat may have been a good decision on a COBOL projectoften proves to be the kiss of death to a Java project. Were clearly seeing this problemonce again as we move to agile software processes. Management needs to change withthe times.

6. Organizational challenges. Common problems such aspoor communications or politicsbetween individuals and groups hurt the data aspects of software development just asbadly as they hurt other efforts.

7. Poor documentation. Most documentation seems to be at one extreme or another: little orno documentation or overly complex documentation that nobody reads. Mutually agreed todevelopment standards and guidelines, legacy system documentation, legacy databasedocumentation, and enterprise models can be valuable resources when written well. Agiledocumentation is definitely critical to your success.

8. Ineffective architectural efforts. Most organizations face significant challenges when itcomes to enterprise architecture, the most common challenge being that they dont evenknow where to start. Biased enterprise architectures, those that overly focus on one view ofthe enterprise, lead to architectures that do not adequately address the real needs of yourorganization. As theZachman Framework indicates, there are many potential views (whichZachman unfortunately refers to as components, a loaded term) that you want to consider,a concept captured byAMsMultiple Models principle. These views are data,function/process, network, people, time, motivation. Ivory tower architectures, thoseformulated by teams that have removed themselves from the day-to-day realities of projectteams, look good on paper but unfortunately fail in practice. Developers unwillingness toconform to the constraints imposed upon them byenterprise architectural models,if theyeven know that such models exist, is also a common and serious problem.

9. Ineffective development guidelines. Many organizations struggle to come to a collection

of development guidelines that all IT professionals will work to. There is a large number ofcauses for this, including people not understanding the need to follow such guidelines,people unwilling to follow someone elses guidelines, overly complex guidelines, overlysimplistic guidelines, a one size fits all attitude that leads to inappropriate guidelines for aspecific platform, and an unwillingness to evolve guidelines over time. When you have aneffective collection of guidelines available to you, and everyone understands and appliesthem appropriately, you can dramatically improve the productivity of your IT efforts. Imaintain lists ofcoding guidelines andmodeling style guidelines.

10. Ineffective modeling efforts. This is often the result of several of the previously identifiedproblems. People focused on a specific aspect of development will often produce modelsthat wonderfully reflect the priorities of that narrow view but that dont take into account therealities of other views. An enterprise data model may present an excellent vision of thedata required by an organization, but an enterprise model that reflects the data, functional,usage, and technical requirements of an organization is likely far more useful. AUML classdiagram may reflect the needs of a single project, but if it doesnt reflect the realities of thelegacy data sources that it will access then it is of little value in practice. Modelers, and ITprofessionals in general, need to work together and look at the full picture to be trulyeffective.

1.1 Warning Signs That You've Got A Problem
http://www.agilemodeling.com/essays/communication.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.zifa.com/http://www.agilemodeling.com/http://www.agilemodeling.com/http://www.agilemodeling.com/principles.htm#MultipleModelshttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.ambysoft.com/essays/codingGuidelines.htmlhttp://www.agilemodeling.com/style/http://www.agilemodeling.com/essays/umlDiagrams.htmhttp://www.agilemodeling.com/essays/umlDiagrams.htmhttp://www.agilemodeling.com/style/http://www.ambysoft.com/essays/codingGuidelines.htmlhttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agilemodeling.com/principles.htm#MultipleModelshttp://www.agilemodeling.com/http://www.zifa.com/http://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/communication.htm


3/7

It is very easy for organizations to deny that they have a problem. It can be very difficult for seniormanagement to detect problems until its too late because the bad news that they need t o hear isfiltered out long before it gets to them. It can be difficult for people elsewhere in the organization todetect problems, perhaps everything is going quite well in their opinionunfortunately the valuesystem that theyre using to judge the situation isnt ideal, making them blind to the problems thatthey are causing. The following is a list of potential symptoms, each of which may indicate that yourorganization has one or more challenges that the Agile Data method may help you to address:

People are significantly frustrated with the efforts, or lack thereof, of one or more groups.

Software is not being developed, or if it is it is taking much too long.

Finger pointing occurs, the data administrators are holding up progress or the developersarent following corporate guidelines are common complaints.Worse yet, the finger pointerdoesnt perceive that they are also part of the problem.

Political issues are given higher priority than working together to development, maintain,and support software-based systems.

Ongoing feuds exist between people/groups. Phrases like you always and you neverare very good clues that feuds exist.

Well-known problems within your organization are not being addressed. Furthermore,suggestions for improvements appear to be ignored, nothing happens and no reason for

rejection is provided. People are working excessively long hours with little or no reward.

Decisions affecting teams, in particular project teams, are made in an apparently arbitraryand arrogant fashion.

We need to find a way to work together effectively. There are clear differences between the dataand development communities, and between the project and enterprise communities. The fact thatwere talking about different communities isalso part of the problem, arguably one of the rootscauses. You have a fundamental decision to make: Should you use these differences as an excuseto exacerbate existing problems within your organization or should you revel in these differencesand find a way to take advantage of them? I prefer the latter. My experience is that the values andprinciples of the agile movement form the basis for an effective approach to working together.

2. The Agile Movement

To address the challenges faced by software developers an initial group of 17 methodologistsformed the Agile Software Development Alliance (www.agilealliance.com), often referred to simplyas the Agile Alliance, in February of 2001. An interesting thing about this group is that they allcame from different backgrounds, yet were able to come to an agreement on issues thatmethodologists typically dont agree upon. This group of people defined a manifesto forencouraging better ways of developing software, and then based on that manifesto formulated acollection of principles which defines the criteria for agile software development processes such asAgile Modeling.Themanifesto is defined by four simple value statementsthe important thing to understand is thatwhile you should value the concepts on the right hand side you should value the things on the lefthand side (presented in bold) even more. A good way to think about the manifesto is that it definespreferences, not alternatives, encouraging a focus on certain areas but not eliminating others. TheAgile Alliancevalues:

1. Individuals and interactionsover processes and tools.2. Working softwareover comprehensive documentation.3. Customer collaborationover contract negotiation.4. Responding to changeover following a plan.
http://www.agilealliance.com/http://www.ambysoft.com/essays/agileManifesto.htmlhttp://www.ambysoft.com/essays/agileManifesto.html#Valueshttp://www.ambysoft.com/essays/agileManifesto.html#Valueshttp://www.ambysoft.com/essays/agileManifesto.htmlhttp://www.agilealliance.com/


4/7

The interesting thing about these value statements is there are something that almost everyone willinstantly agree to, yet will rarely adhere to in practice. Senior management will always claim that itsemployees are the most important aspect of your organization, yet insist they follow ISO-9000compliant processes and treat their staff as replaceable assets. Even worse, management oftenrefuses to provide sufficient resources to comply to the processes that they insist project teamsfollow. Everyone will readily agree that the creation of software is the fundamental goal of softwaredevelopment, yet insist on spending months producing documentation describing what the softwareis and how it is going to be built instead of simply rolling up their sleeves and building it. You getthe ideapeople say one thing and do another. This has to stop now. Agile developers do whatthey say and say what they do.To help people to gain a better understanding of what agile software development is all about, themembers of the Agile Alliance refined the philosophies captured in their manifesto into a collectionoftwelve principles.Agile software development methodologies, such as Scrum and moreimportantlyDisciplined Agile Delivery (DAD),should conform to. These principles are:

1. Our highest priority is to satisfy the customer through early and continuous delivery ofvaluable software.

2. Welcome changing requirements, even late in development. Agile processes harnesschange for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter time scale.4. Business people and developers must work together daily throughout the project.5. Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done.6. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.7. Working software is the primary measure of progress.8. Agile processes promote sustainable development. The sponsors, developers, and users

should be able to maintain a constant pace indefinitely.9. Continuous attention to technical excellence and good design enhances agility.10. Simplicitythe art of maximizing the amount of work not doneis essential.11. The best architectures, requirements, and designs emerge from self-organizing teams.12. At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.

Stop for a moment and think about these principles. Is this the way that your software projectsactually work? Is this the way that you think projects should work? Re-read the principles onceagain. Are they radical and impossible goals as some people would claim, are they meaninglessmotherhood and apple pie statements, or are they simply common sense? My belief is that theseprinciples form a foundation of common sense upon which you can base successful softwaredevelopment efforts. A foundation that can be used to direct the data-oriented efforts of ITprofessionals.For a detailed explanation of the values and principles of the agile movement, you mayfindExamining the Agile Manifesto of interest.

3. The Philosophies of Agile Data
http://www.ambysoft.com/essays/agileManifesto.html#Principleshttp://disciplinedagiledelivery.com/http://www.ambysoft.com/essays/agileManifesto.htmlhttp://www.ambysoft.com/essays/agileManifesto.htmlhttp://disciplinedagiledelivery.com/http://www.ambysoft.com/essays/agileManifesto.html#Principles


5/7

The Agile Data method is defined by itssix philosophies:

1. Data.2. Enterprise issues.3. Enterprise groups.4. Uniqueness.

5. Teamwork.6. Sweet spot.

An interesting observation is that most of these philosophies arent specific to data, instead they areapplicable to information technology efforts in general. As the first principle implies you need to lookat the overall picture and not just data, therefore data-specific principles very likely wont serve youvery well. Heresy? No, just common sense.

4. Roles with the Agile Data Method

The Agile Data method defines four rolesApplication Developer, Agile DBA, EnterpriseAdministrator, and Enterprise Architectthat IT professionals will fulfill. These roles, and how theywork together, are discussed in greater detail inThe Roles of Agile Data.Table 1 summarizes theimplications of the Agile Data method for IT professionals, implications that are also covered inTheRoles of Agile Data.

Table 1. Implications for IT professionals.

Role Implications

Everyone

Everyone must agree to a common vision as to what they are trying toaccomplish and how theyre going to accomplish it.

Agile software developers are willing to work with others and co-locate asneeded.

Documentation is a reality of software development. Choose to be agile

in your approach. Agile software developers strive to be generalists with one or more

specialties.

Agile software developers are flexible in their approach because oneprocess size does not fit all.

Software is your primary goal, enabling the next effort is your secondarygoal.

ApplicationDevelopers

Application developers must work closely with project stakeholders.

Application developers must recognize that legacy systems anddatabases place constraints on them.

Application developers should follow their organizations standards andguidelines and be willing to provide feedback into their ongoing evolution.

Application developers will work closely with enterprise architects, peoplewho should become active members of a project team.

Agile DBAs

Agile DBAs work very closely with application developers to implementand support data-oriented development efforts.

Agile DBAs must be willing to work in an iterative and incrementalmanner, just as application developers do.

Agile DBAs will work with enterprise administrators to take advantage of
http://www.agiledata.org/essays/philosophies.htmlhttp://www.agiledata.org/essays/philosophies.html#Datahttp://www.agiledata.org/essays/philosophies.html#EnterpriseIssueshttp://www.agiledata.org/essays/philosophies.html#EnterpriseGroupshttp://www.agiledata.org/essays/philosophies.html#Uniquenesshttp://www.agiledata.org/essays/philosophies.html#Teamworkhttp://www.agiledata.org/essays/philosophies.html#SweetSpothttp://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/vision.html#Table1http://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/developerSkills.htmlhttp://www.agiledata.org/essays/developerSkills.htmlhttp://www.agiledata.org/essays/developerSkills.htmlhttp://www.agiledata.org/essays/dbaSkills.htmlhttp://www.agiledata.org/essays/dbaSkills.htmlhttp://www.ambysoft.com/books/agileDatabaseTechniques.htmlhttp://www.agiledata.org/essays/dbaSkills.htmlhttp://www.agiledata.org/essays/developerSkills.htmlhttp://www.agiledata.org/essays/developerSkills.htmlhttp://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/vision.html#Table1http://www.agiledata.org/essays/roles.htmlhttp://www.agiledata.org/essays/philosophies.html#SweetSpothttp://www.agiledata.org/essays/philosophies.html#Teamworkhttp://www.agiledata.org/essays/philosophies.html#Uniquenesshttp://www.agiledata.org/essays/philosophies.html#EnterpriseGroupshttp://www.agiledata.org/essays/philosophies.html#EnterpriseIssueshttp://www.agiledata.org/essays/philosophies.html#Datahttp://www.agiledata.org/essays/philosophies.html


6/7

and to help evolve corporate meta data, standards, and guidelines.

EnterpriseAdministrators

There is more to enterprise administration than data administration.

The primary goal of enterprise administrators is to support project teamefforts, helping to guide the teams towards solutions that reflect theoverall needs of the enterprise.

Enterprise administrators develop and support collections of flexiblestandards and guidelines that reflect the actual needs of developers, notthe artificial needs of bureaucrats.

Enterprise administrators support and work with others in the organizationto communicate the constraints imposed by the current environment.

EnterpriseArchitects

Enterprise architects focus on more than just data architecture.

Enterprise architects work in an iterative and incremental manner.

Enterprise architects actively work with project teams to communicate thearchitecture, to mentor project teams in architecture and modeling skills,and to gain real-world feedback that they use to evolve the architecture.

5. Does Agile Data Solve Our Problems?

An important question to ask is whether the philosophies and suggested cultural changes addressthe problems that organizations face when it comes to the data aspects of softwaredevelopment.Table 2 shows that this in fact is the case, listing the potential problems and thesolution suggested by the Agile Data method.Table 2. How the individual problems are addressed.

Problem Solution

Different visionsand priorities

Agile Data implores IT professionals to work together, to understand and respectthe viewpoints of your co-workers.

Overspecialization ofroles

Agile Data asks IT professionals to find the sweet spot between the extremes ofbeing a generalist and being a specialist by becoming someone who is ageneralist with one or more specialties.

Processimpedancemismatch

Agile Data implores enterprise and data professionals to be prepared to workfollowing an incremental and iterative approach, the norm for most moderndevelopment and the defacto standard for agile software development. It alsoimplores application developers to recognize that the existing environment, andfuture vision for the organization, places constraints on their efforts.

Technologyimpedancemismatch

Agile Data requires that IT professionals work together closely, learning fromeach other as they do so. Agile DBAs have the skills to map the applicationschema to the data schema, to write data-oriented code, and to performancetune their work.

Ossifiedmanagement

Agile Data asks enterprise architects to work with senior management and

educate them in the realities of modern software development. Similarlyapplication developers should work with and help to educate both line and middlemanagement.

Organizationalchallenges

Agile Data implores IT professionals to work with one another and with yourproject stakeholders, to respect them and to actively strive to work togethereffectively.

Poordocumentation

Agile Data directs IT professionals to follow the principles ofAgileDocumentation.

Ineffective Agile Data advises enterprise architects to take a multi-view/model approach to
http://www.agiledata.org/essays/enterpriseAdministration.htmlhttp://www.agiledata.org/essays/enterpriseAdministration.htmlhttp://www.agiledata.org/essays/enterpriseAdministration.htmlhttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agiledata.org/essays/vision.html#Table1http://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agilemodeling.com/essays/agileDocumentation.htmhttp://www.agiledata.org/essays/vision.html#Table1http://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agiledata.org/essays/enterpriseArchitecture.htmlhttp://www.agiledata.org/essays/enterpriseAdministration.htmlhttp://www.agiledata.org/essays/enterpriseAdministration.html


7/7

architecturalefforts

architecture and to actively work on project team to support and prove theirarchitecture. The feedback from these efforts should then be reflected in futureiterations of the architecture.

Ineffectivedevelopmentguidelines

Agile Data implores enterprise administrators to write clear, effective, andapplicable standards and guidelines and to be prepared to act on feedback fromthe development teams.

Ineffectivemodeling efforts

Agile Data directs IT professionals to follow the principles and practices oftheAgile Modeling methodology.

- See more at: http://www.agiledata.org/essays/vision.html#sthash.amd44EWL.dpuf
http://www.agilemodeling.com/http://www.agilemodeling.com/

resumen am

Documents