[English] - [Cymraeg]
I’m Adam Gwinnett, the Architecture Lead for the CJS Common Platform Programme. I’d like to take some time to explain how we are following the Agile software methodology in the development and delivery of our products and services.
During my time working on the Programme, the digital delivery lifecycle (Discovery – Alpha – Beta - Live) has raised interesting questions about the role of architecture and the applicability of traditional approaches (Enterprise Architecture, TOGAF etc) to Agile software delivery.
When delivering a change or transformation programme such as the CJS Common Platform, it’s important to consider architecture work in advance of engaging a formal delivery team, This provides the context and business vision that the team will work towards.
This would be overkill for individual products, as the required design elements could be addressed during Discovery. However, where there are multiple product teams with dependencies to support releases, this coordination can provide a degree of security between teams and increase visibility of scope and approach for stakeholders.
I have developed some guidance which might help other similar programmes going down the Agile route:
Just Enough Design Up Front (JEDUF)
- Design teams should strongly resist urges to spend months of design activity and analysis in advance to ensure the problem is "understood" and risk limiting the scope of the teams to explore and deliver options
- Detailed technical designs should not be produced in anticipation of what the user research will surface, design assumptions at this phase are least likely to be borne out by the product
- Focus for initial design phases should be used exclusively to shape the project Discovery by ensuring it is clear what services and re-usable elements are expected from its delivery where these might not be immediately apparent to the Discovery team
- The output from the initial design activity should be aligned the business and technical vision for the services, the relationships between product teams and any constraints that may not emerge from user research
- Design should probably stop at a bounded context map of the expected services, defining their capabilities but not addressing the technical implementation of those except where strictly necessary
- The larger the delivery activity and the more parallel delivery streams, the amount of effort required in advance is more likely to grow proportionately. If a programme of work is too large, this will be flagged up by the anticipated advance effort extending for more than a 6-8 week period.
- Effort should focus on agreeing the governance and communication cycles that will facilitate sharing between teams (that may not be geographically co-located) to avoid duplication of effort and dependency mis-match
During the digital delivery lifecycle, note the following outputs/products
Discovery
- Expect a High Level Solution Architecture (HLSA) or initial view of services and software elements/products (this is unlikely to be a formal document, but may be a small number of diagrams or a wiki page)
- Encourage a technical spike of a concept to see if it behaves as the team anticipate
- Limited oversight should be required in this phase, but time from any central function should be set aside for the team to validate their thinking with as needed, but this should be driven by the Discovery team
Alpha
- Should have the equivalent of a High Level Design (HLD) to inform the environments view and demonstrate approaches to others consuming it. This shouldn't necessarily be in a formal document and should emerge over the course of Alpha as development is undertaken and not be crystallised at the start
- Opportunities should be taken to consider alternative ways of instantiating the service and testing these against the architectural principles to test alignment, this alignment can be demonstrated through normal show and tells for the products
- Feedback and sharing of thinking should be informal and frequent, as this phase is most likely to see regular and widespread changes to the proposed model and when most lessons about the product will be learned from the delivery team
Beta
- A Low Level Design (LLD) equivalent body of material will come into existence over this phase on what the deployment/implementation model will look like including clustering, scaling approaches, patching / maintenance of libraries/products and a view on formal Non Functional Testing (NFT) in preparation for production. As much of this should be automated and done in Sprint by the teams as possible, limiting the exposure and delay to production deployment at the end of the phase
- Focus should be on how the API presents itself and alignment with the API principles, as that should be the primary model for engaging/using the service. The majority of services delivered should be headless and presume that consumers will use service calls from their own APIs rather than consuming the service as an "app".
- User feedback should now be received from actual end users and any discussed service enhancement will need to be balanced against other services with a view to avoiding duplication
I’ll use this blog to set out my further thoughts but in the meantime I look forward to your views on my observations.
[English] - [Cymraeg]
DABLo gyda phensaernïaeth
Adam Gwinnett ydw i, sef yr Arweinydd Pensaernïol ar gyfer Rhaglen Platfform Cyffredin y System Cyfiawnder Troseddol. Hoffwn gymryd ychydig o amser i egluro sut ydym yn dilyn methodoleg y meddalwedd Agile wrth ddatblygu a darparu ein cynhyrchion a’n gwasanaethau.
Yn ystod fy nghyfnod yn gweithio ar y Rhaglen, mae’r cylch cyflawni digidol (Discovery - Alpha - Beta - Live) wedi codi cwestiynau diddorol am rôl pensaernïaeth a pherthnasedd dulliau traddodiadol (Enterprise Architecture, TOGAF, ac ati) o ran darparu meddalwedd Agile.
Wrth gyflawni newid neu raglen trawsnewid fel Platfform Cyffredin y System Cyfiawnder Troseddol, mae’n bwysig ystyried gwaith pensaernïol ymlaen llaw, cyn cysylltu â’r tîm cyflawni ffurfiol. Mae hyn yn darparu’r cyd-destun a’r weledigaeth busnes y bydd y tîm yn gweithio tuag ati.
Byddai hyn yn ormod i gynnyrch unigol, oherwydd gellid mynd i’r afael â’r elfennau dylunio gofynnol gael eu cyfarch yn ystod y cyfnod Discovery. Serch hynny, ble ceir sawl tîm cynnyrch gyda dibyniaethau i gefnogi allbynnau, gall y cydlynu hyn ddarparu rhywfaint o ddiogelwch rhwng timau a chynyddu gwelededd y cwmpas a'r dull i rhanddeiliaid.
Rwyf wedi datblygu peth gyfarwyddyd a allai fod o gymorth i raglenni tebyg sy’n dilyn y trywydd Agile:
Just Enough Design Up Front (JEDUF)
- Dylai’r timau dylunio wrthsefyll yr awydd i dreulio misoedd ar weithgaredd dylunio a dadansoddi ymlaen llaw i sicrhau bod y broblem “wedi’i deall” a chymryd y perygl o gyfyngu ar allu eu timau i archwilio a chyflawni opsiynau
- Ni ddylai'r dyluniadau technegol gael eu cynhyrchu i baratoi am beth fydd yn codi o’r ymchwil defnyddwyr, mae rhagdybiaethau dylunio yn llai tebygol o gael eu profi gan y cynnyrch
- Dylai’r ffocws am y camau dylunio cychwynnol gael ei ddefnyddio i lywio cam Discovery y prosiect gan sicrhau ei fod yn glir pa wasanaethau ac elfennau gellir eu hailddefnyddio y disgwylir o’i gyflawni efallai na fyddai wedi bod yn amlwg i'r tîm Discovery.
- Dylai’r allbynnau o’r gweithgaredd dylunio cychwynnol gyd-fynd â'r weledigaeth busnes a thechnegol i'r gwasanaethau, y perthnasau rhwng y timau prosiect ac unrhyw gyfyngiadau efallai na fyddai'n codi o'r ymchwil defnyddwyr
- Dylai’r dylunio fynd cyn belled â map cyd-destun ffinedig y gwasanaethau disgwyliedig, gan ddiffinio’r medrau ond peidio â chyfarch y gweithrediad technegol ar eu cyfer, heblaw pa fo’r angen
- Y mwyaf y gweithgaredd cyflawni a’r mwyaf yw’r llwybrau cyflawni paralel, mae'r ymdrech bydd ei angen ymlaen llaw yn fwy tebygol o gynyddu'n gyfatebol. Os yw rhaglen waith yn rhy fawr, bydd hyn yn cael ei amlygu gan yr ymdrech ymlaen llaw a rhagwelir y byddai’n cael ei ymestyn am gyfnod o 6-8 wythnos.
- Dylai’r ymdrech ganolbwyntio ar gytuno ar y cylchoedd llywodraethol a chyfathrebu a fydd yn hwyluso rhannu gwybodaeth rhwng timau (efallai na fyddant wedi'u cydleoli'n ddaearyddol) i osgoi dyblygu’r ymdrech ac arwain at ddibyniaethau anghydnaws
Yn ystod y cylch oes cyflawni digidol, nodwch yr allbynnau/cynhyrchion a ganlyn:
Discovery
- Disgwyliwch Pensaernïaeth Datrys Lefel Uchel (HLSA) neu olwg cychwynnol o wasanaethau ac elfennau meddalwedd/cynhyrchion (nid yw hyn yn debygol o fod yn ddogfen ffurfiol, ond efallai bydd yn cynnwys nifer fach o ddiagramau neu dudalen wiki)
- Annog brig technegol i gysyniad i weld os yw’n ymddwyn fel y mae’r tîm yn disgwyl
- Dylai arolygiaeth gyfyngol fod yn ofynnol yn y cam hwn, ond dylid neilltuo amser i unrhyw swyddogaeth ganolog i'r tîm ddilysu eu syniadau fel y gofyn, ond dylai'r Tîm Discovery arwain ar hyn.
Alpha
- Dylai fod yn rhywbeth sy’n gyfwerth â Dyluniad Lefel Uchel (HLD) i gyfarwyddo barn yr amgylchedd ac arddangos dulliau i eraill sy'n ei ddefnyddio. Ni ddylai hyn o reidrwydd fod yn ddogfen ffurfiol a dylid ymddangos yn raddol dros gyfnod Alpha wrth iddo ddatblygu a pheidio â chael ei grisialu yn y cychwyn
- Dylid cymryd cyfleoedd i ystyried ffyrdd amgen o enghreifftio'r gwasanaeth a phrofi'r rhain yn erbyn yr egwyddorion pensaernïol i brofi unioniad, gellir arddangos yr unioniad hwn drwy sesiynau dangos a dweud ar gyfer y cynhyrchion.
- Dylid cael adborth a rhannu syniadau yn aml ac yn anffurfiol, oherwydd y cam hwn sydd fwyaf tebygol o brofi newidiadau cyson ac eang i’r model arfaethedig a phan fydd y tîm cyflawni yn dysgu’r mwyafrif o’r gwersi am y cynnyrch
Beta
- Bydd corff o ddeunydd sy’n gyfwerth â Dyluniad Lefel Isel (LLD) yn dod i fodolaeth yn ystod y cam hwn am sut fydd y model lleoli/gweithredu yn edrych gan gynnwys clystyru, graddio dulliau, patching / cynnal a chadw llyfrgelloedd / cynhyrchion a golwg ar Brofi Anymarferol Ffurfiol (NFT) i baratoi ar gyfer cynhyrchu. Oherwydd dylai llawer o hyn gael ei wneud yn awtomatig a’i wneud yn gyflym gan y timau fel bo modd, gan gyfyngu ar ddatguddio ac oedi gyda gweithredu cynhyrchion ar ddiwedd y cam hwn
- Dylai’r ffocws fod ar sut mae'r API yn cyflwyno ei hun a'r unioniad gyda'r egwyddorion API oherwydd dylai hynny fod y prif fodel ar gyfer defnyddio'r gwasanaeth. Ni ddylai’r mwyafrif o’r gwasanaethau a ddarperir fod â phennaeth a rhagdybio bydd defnyddwyr yn defnyddio galwadau gwasanaeth o’u APIs eu hunain yn hytrach na ddefnyddio'r gwasanaeth fel "ap".
- Dylai adborth nawr gael ei dderbyn gan ddefnyddwyr y gwasanaeth a bydd rhaid cydbwyso unrhyw welliant i'r gwasanaeth a drafodir yn erbyn gwasanaethau eraill, gyda'r nod o osgoi dyblygu
Byddaf yn defnyddio’r blog hwn i gyfleu fy meddyliau pellach ond yn y cyfamser rwy'n edrych ymlaen at glywed eich barn ar fy sylwadau.
